[要約] 要約：RFC 2847は、SPKMを使用した低インフラストラクチャ公開鍵メカニズムであるLIPKEYについての情報を提供しています。 目的：LIPKEYは、低コストでセキュアな公開鍵暗号化を実現するために設計されており、SPKMを使用して鍵の生成、交換、管理を行います。
Network Working Group M. Eisler
Request for Comments: 2847 Zambeel
Category: Standards Track June 2000
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
リプキー - SPKMを使用した低いインフラストラクチャ公開キーメカニズム
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol [RFC2246].
この覚書は、GSS-API [RFC2078]を使用してクライアントとサーバーの間に安全なチャネルを提供し、パスワードを使用してクライアントに認証し、公開鍵証明書を持つサーバーを提供できる方法を説明しています。そのため、輸送層セキュリティ（TLS）プロトコルの一般的な低インフラストラクチャの使用に類似しています[RFC2246]。
The method leverages the existing Simple Public Key Mechanism (SPKM) [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM.
このメソッドは、既存の単純な公開キーメカニズム（SPKM）[RFC2025]を活用し、SPKMの上に階層化された別のGSS-APIメカニズム（LIPKEY）として指定されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LIPKEY's Requirements of SPKM . . . . . . . . . . . . . . . . 4
2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
2.4. Context Establishment Tokens . . . . . . . . . . . . . . . . 8
2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . . 8
2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . . 9
2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Quality of Protection (QOP) . . . . . . . . . . . . . . . .10
3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . 11
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 11
3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 11
3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 12
3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE . . . . 12
3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE . . . . 13
3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . 14
3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 14
3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 14
3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 15
4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 15
4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 16
4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment . 16
4.3.1.2. Post-SPKM-3 Context Establishment Tokens . . . . . . . 16
4.3.1.2.1. From LIPKEY Initiator . . . . . . . . . . . . . . . 17
4.3.1.2.2. From LIPKEY Target . . . . . . . . . . . . . . . . . 17
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 17
4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 18
5.1. Password Management . . . . . . . . . . . . . . . . . . . 18
5.2. Certification Authorities . . . . . . . . . . . . . . . . 18
5.3. HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 18
5.4. Security of cast5CBC . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 22
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This memorandum describes a new security mechanism under the GSS-API called the Low Infrastructure Public Key Mechanism (LIPKEY). GSS-API provides a way for an application protocol to implement authentication, integrity, and privacy. TLS is another way. While TLS is in many ways simpler for an application to incorporate than GSS-API, there are situations where GSS-API might be more suitable. Certainly this is the case with application protocols that run over connectionless protocols. It is also the case with application protocols such as ONC RPC [RFC1831] [RFC2203], which have their own security architecture, and so do not easily mesh with a protocol like TLS that is implemented as a layer that encapsulates the upper layer application protocol. GSS-API allows the application protocol to encapsulate as much of the application protocol as necessary.
この覚書は、低インフラストラクチャ公開キーメカニズム（LIPKEY）と呼ばれるGSS-APIの下での新しいセキュリティメカニズムについて説明しています。GSS-APIは、アプリケーションプロトコルが認証、整合性、プライバシーを実装する方法を提供します。TLSは別の方法です。TLSは、GSS-APIよりもアプリケーションを組み込むために多くの点で簡単ですが、GSS-APIがより適切になる可能性がある状況があります。確かに、これは、コネクションレスプロトコルを実行するアプリケーションプロトコルの場合です。また、独自のセキュリティアーキテクチャを備えたONC RPC [RFC1831] [RFC2203]などのアプリケーションプロトコルの場合もそうです。。GSS-APIを使用すると、アプリケーションプロトコルは、必要に応じてアプリケーションプロトコルを多くカプセル化できます。
Despite the flexibility of GSS-API, it compares unfavorably with TLS with respect to the perception of the amount of infrastructure required to deploy it. The better known GSS-API mechanisms, Kerberos V5 [RFC1964] and SPKM require a great deal of infrastructure to set up. Compare this to the typical TLS deployment scenario, which consists of a client with no public key certificate accessing a server with a public key certificate. The client:
GSS-APIの柔軟性にもかかわらず、それを展開するために必要なインフラストラクチャの量の認識に関して、TLSと不利に比較されます。よく知られているGSS-APIメカニズムであるKerberos V5 [RFC1964]およびSPKMは、セットアップするために多くのインフラストラクチャが必要です。これを典型的なTLS展開シナリオと比較します。これは、公開キー証明書が公開されていない公開キー証明書のないクライアントで構成されています。クライアント：
* obtains the server's certificate,
* サーバーの証明書を取得します。
* verifies that it was signed by a trusted Certification Authority (CA),
* 信頼できる認証機関（CA）によって署名されたことを確認します。
* generates a random session symmetric key,
* ランダムなセッション対称キーを生成します。
* encrypts the session key with the server's public key, and
* セッションキーをサーバーの公開キーで暗号化し、
* sends the encrypted session key to the server.
* 暗号化されたセッションキーをサーバーに送信します。
At this point, the client and server have a secure channel. The client can then provide a user name and password to the server to authenticate the client. For example, when TLS is being used with the http protocol, once there is a secure channel, the http server will present the client with an html page that prompts for a user name and password. This information is then encrypted with the session key and sent to the server. The server then authenticates the client.
この時点で、クライアントとサーバーには安全なチャネルがあります。クライアントは、ユーザー名とパスワードをサーバーに提供して、クライアントを認証できます。たとえば、TLSがHTTPプロトコルで使用されている場合、安全なチャネルがあると、HTTPサーバーは、ユーザー名とパスワードをプロンプトするHTMLページをクライアントに提示します。この情報は、セッションキーで暗号化され、サーバーに送信されます。サーバーはクライアントを認証します。
Note that the client is not required to have a certificate for itself to identify and authenticate it to the server. In addition to a TLS implementation, the required security infrastructure includes a public key certificate and password database on the server, and a list of trusted CAs and their public keys on the client. Most operating systems that the http server would run on already have a native password database, so the net additional infrastructure is a server certificate and CA list. Hence the term "low infrastructure security model" to identify this typical TLS deployment scenario.
クライアントは、それをサーバーに識別して認証するための証明書を持つ必要がないことに注意してください。TLSの実装に加えて、必要なセキュリティインフラストラクチャには、サーバー上の公開キー証明書とパスワードデータベース、およびクライアントに信頼できるCAとそのパブリックキーのリストが含まれています。HTTPサーバーが実行されるほとんどのオペレーティングシステムには、ネイティブパスワードデータベースが既にあるため、ネット追加のインフラストラクチャはサーバー証明書とCAリストです。したがって、この典型的なTLS展開シナリオを識別する「低インフラストラクチャセキュリティモデル」という用語。
By using unilateral authentication, and using a mechanism resembling the SPKM-1 mechanism type, SPKM can offer many aspects of the previously described low infrastructure security model. An application that uses GSS-API is certainly free to use GSS-API's GSS_Wrap() routine to encrypt a user name and password and send them to the server, for it to decrypt and verify.
一方的な認証を使用し、SPKM-1メカニズムタイプに似たメカニズムを使用することにより、SPKMは以前に記載された低インフラストラクチャセキュリティモデルの多くの側面を提供できます。GSS-APIを使用するアプリケーションは、GSS-APIのGSS_WRAP（）ルーチンを使用して、ユーザー名とパスワードを暗号化してサーバーに送信することができます。
Applications often have application protocols associated with them, and there might not be any provision in the protocol to specify a password. Layering a thin GSS-API mechanism over a mechanism resembling SPKM-1 can mitigate this problem. This can be a useful approach to avoid modifying applications that have already bound to GSS-API, assuming the applications are not statically bound to specific GSS-API mechanisms. The remainder of this memorandum defines the thin mechanism: the Low Infrastructure Public Key Mechanism (LIPKEY).
アプリケーションには多くの場合、アプリケーションプロトコルが関連付けられており、パスワードを指定するためのプロトコルに規定がない場合があります。SPKM-1に似たメカニズムを介して薄いGSS-APIメカニズムを重ねると、この問題を軽減できます。これは、アプリケーションが特定のGSS-APIメカニズムに静的にバインドされていないと仮定して、すでにGSS-APIに拘束されているアプリケーションを変更することを避けるための有用なアプローチになります。この覚書の残りの部分は、薄いメカニズム、つまり低いインフラストラクチャの公共キーメカニズム（Lipkey）を定義しています。
SPKM-1 with unilateral authentication is close to the desired low infrastructure model described earlier. This section describes some additional changes to how SPKM-1 operates in order to realize the low infrastructure model. These changes include some minor changes in semantics. While it would be possible to implement these semantic changes within an SPKM-1 implementation (including using the same mechanism type Object Identifier (OID) as SPKM-1), the set of changes stretch the interpretation of RFC 2025 to the point where compatibility would be in danger. A new mechanism type, called SPKM-3, is warranted. LIPKEY requires that the SPKM implementation support SPKM-3. SPKM-3 is equivalent to SPKM-1, except as described in the remainder of this section.
一方的な認証を使用したSPKM-1は、前述の目的の低インフラストラクチャモデルに近いものです。このセクションでは、低インフラストラクチャモデルを実現するために、SPKM-1がどのように動作するかについての追加の変更について説明します。これらの変更には、セマンティクスのいくつかの小さな変更が含まれます。SPKM-1実装内でこれらのセマンティック変更を実装することは可能ですが（SPKM-1と同じメカニズムタイプオブジェクト識別子（OID）を使用することを含む）、一連の変更はRFC 2025の解釈を互換性のあるポイントに広げます危険にさらされてください。SPKM-3と呼ばれる新しいメカニズムタイプが保証されます。Lipkeyでは、SPKMの実装がSPKM-3をサポートする必要があります。SPKM-3は、このセクションの残りの部分で説明されている場合を除き、SPKM-1に相当します。
SPKM-3 has a different mechanism type OID from SPKM-1.
SPKM-3には、SPKM-1とは異なるメカニズム型OIDがあります。
spkm-3 OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)spkm(1)spkm-3(3)}
RFC 2025 defines no required name types of SPKM. LIPKEY requires that the SPKM-3 implementation support all the mechanism independent name types in RFC 2078.
RFC 2025は、SPKMの必要な名前の種類を定義していません。Lipkeyは、SPKM-3実装がRFC 2078のすべてのメカニズム独立名タイプをサポートすることを要求しています。
RFC 2025 defines various algorithms for integrity, confidentiality, key establishment, and subkey derivation. Except for md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG), Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG) algorithms listed in RFC 2025 continue to be REQUIRED.
RFC 2025は、整合性、機密性、主要な設立、およびサブキー派生のためのさまざまなアルゴリズムを定義しています。MD5WithRSAENCRYPTIONを除き、RFC 2025にリストされているサブキー派生（O-ALG）アルゴリズムの必要なキー確立（K-ALG）、I-ALG）、および一元配置関数は引き続き必要です。
SPKM is designed to be extensible with regard to new algorithms. In order for LIPKEY to work correctly and securely, the following algorithms MUST be implemented in SPKM-3:
SPKMは、新しいアルゴリズムに関して拡張可能になるように設計されています。Lipkeyが正しく安全に機能するためには、次のアルゴリズムをSPKM-3に実装する必要があります。
* Integrity algorithms (I-ALG)
* 整合性アルゴリズム（i-alg）
NULL-MAC Because the initiator may not have a certificate for itself, nor for the target, it is not possible for it to calculate an Integrity value in the initiator's REQ-TOKEN that is sent to the target. So we define, in ASN.1 [CCITT] syntax, a null I-ALG that returns a zero length bit string regardless of the input passed to it:
null-macイニシエーターは、それ自体の証明書を持っていないため、またターゲットの証明書を持っていないため、ターゲットに送信されるイニシエーターのreqトークンの整合性値を計算することはできません。したがって、asn.1 [ccitt] syntaxで、渡された入力に関係なくゼロの長さビット文字列を返すnull i-algで定義します。
NULL-MAC OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
integrity(3)NULL-MAC(3)}
id-dsa-with-sha1 This is the signature algorithm as defined in Section 7.2.2 of [RFC2459]. As noted in RFC 2459, the ASN.1 OID used to identify this signature algorithm is:
id-dsa-with-sha1これは、[RFC2459]のセクション7.2.2で定義されている署名アルゴリズムです。RFC 2459で述べたように、この署名アルゴリズムを識別するために使用されるASN.1 OIDは次のとおりです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 3
}
Note that there is a work-in-progress [PKIX] to obsolete RFC 2459. However that work-in-progress does not change the definition of id-dsa-with-sha1.
RFC 2459を廃止するための進行中の[pkix]があることに注意してください。ただし、その作業は、id-dsa-with-sha1の定義を変更しないことに注意してください。
HMAC-MD5 A consequence of the SPKM-3 initiator not having a certificate is that it cannot use a digital signature algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or sha1WithRSAEncryption once the context is established. Instead, a message authentication code (MAC) algorithm is required. DES-MAC is specified as recommended in [RFC2025]. Since the security of 56 bit DES has been shown to be inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3 MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:
HMAC-MD5 SPKM-3イニシエーターが証明書を持っていない結果、コンテキストが確立されたら、MD5WithRSaEcryption、ID-DSA-With-Sha1、またはSHA1WithRSaEcryptionなどのデジタル署名アルゴリズムを使用できないことです。代わりに、メッセージ認証コード（MAC）アルゴリズムが必要です。DES-MACは、[RFC2025]で推奨されているように指定されています。56ビットDESのセキュリティは不十分であることが示されているため、SPKM-3にはより強力なMACが必要です。したがって、SPKM-3は、このOIDでHMAC-MD5アルゴリズム[RFC2104]をサポートする必要があります。
HMAC-MD5 OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) isakmpOakley(1)
1
}
The reference for the algorithm OID of HMAC-MD5 is [IANA]. The reference for the HMAC-MD5 algorithm is [RFC2104].
HMAC-MD5のアルゴリズムOIDの参照は[IANA]です。HMAC-MD5アルゴリズムの参照は[RFC2104]です。
The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC because SHA-1 is about half the speed of MD5 [Young]. A MAC based on an encryption algorithm like cast5CBC, DES EDE3, or RC4 is not mandatory because MD5 is 31 percent faster than the fastest of the three encryption algorithms [Young].
HMAC-SHA1アルゴリズムは、SHA-1がMD5 [Young]の約半分の速度であるため、必須のSPKM-3 I-Alg Macではありません。MD5は3つの暗号化アルゴリズム[Young]の中で最も速いよりも31％高速であるため、CAST5CBC、DES EDE3、またはRC4などの暗号化アルゴリズムに基づくMACは必須ではありません。
* Confidentiality algorithm (C-ALG).
* 機密性アルゴリズム（C-Alg）。
RFC 2025 does not have a MANDATORY confidentiality algorithm, and instead has RECOMMENDED a 56 bit DES algorithm. Since the LIPKEY initiator needs to send a password to the target, and since 56 bit DES has been demonstrated as inadequate [EFF], LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this algorithm:
RFC 2025には必須の機密性アルゴリズムがなく、代わりに56ビットDESアルゴリズムを推奨しています。リプキーイニシエーターはターゲットにパスワードを送信する必要があり、56ビットDESが不十分であると実証されているため、リプキーはより強力な暗号化が必要です。したがって、SPKM-3はこのアルゴリズムをサポートする必要があります。
cast5CBC OBJECT IDENTIFIER ::= {
iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
algorithms(66) 10
}
Parameters ::= SEQUENCE {
iv OCTET STRING DEFAULT 0, -- Initialization vector
keyLength INTEGER -- Key length, in bits
}
The reference for the OID and description of the cast5CBC algorithm is [RFC2144]. The keyLength in the Parameters MUST be set to 128 bits.
OIDの参照とCAST5CBCアルゴリズムの説明は[RFC2144]です。パラメーターのキーラングを128ビットに設定する必要があります。
A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C-ALG because it is much slower than cast5CBC. One set of measurements [Young] on a Pentium Pro 200 megahertz processor using the SSLeay code, showed that DES EDE3 performed as high as 1,646,210 bytes per second, using 1024 byte blocks. The same test bed yielded performance of 7,147,760 bytes per second for cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS sessions negotiate the RC4 cipher. Given that LIPKEY is targeted at environments similar to that where TLS is deployed, selecting a cipher that is over 13 times slower (and over 13 times more CPU intensive) than RC4 would severely impede the usefulness of LIPKEY. For performance reasons, RC4 would be the preferred mandatory algorithm for SPKM-3. Due to intellectual property considerations with RC4 [Schneier], the combination of cast5CBC's reasonable performance, and its royalty-free licensing terms [RFC2144] make cast5CBC the optimal choice among DES EDE3, RC4, and cast5CBC.
Triple DES（DES EDE3）アルゴリズムは、CAST5CBCよりもはるかに遅いため、必須のSPKM-3 C-Algではありません。SSLEAYコードを使用したPentium Pro 200 Megahertzプロセッサでの1つの測定[Young]セットは、DES EDE3が1024バイトブロックを使用して1,646,210バイトあたり1,646,210バイトでパフォーマンスを発揮することを示しました。同じテストベッドでは、CAST5CBCで1秒あたり7,147,760バイト、RC4で22,419,840バイトの性能が得られました。ほとんどのTLSセッションはRC4暗号を交渉します。Lipkeyは、TLSが展開されている環境と同様の環境をターゲットにしていることを考えると、RC4よりも13倍遅い（および13倍以上のCPU集中）暗号を選択します。パフォーマンス上の理由から、RC4はSPKM-3の優先強制アルゴリズムになります。RC4 [Schneier]との知的財産の考慮事項により、CAST5CBCの合理的なパフォーマンスとそのロイヤリティフリーライセンス条件[RFC2144]の組み合わせにより、CAST5CBCはDESEDE3、RC4、およびCAST5CBCの最適な選択になります。
* Key Establishment Algorithm (K-ALG)
* キー設立アルゴリズム（k-alg）
RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional algorithm. As will be described later, the RSAEncryption key establishment algorithm is of no use for a low infrastructure security mechanism as defined by this memorandum. Hence, in SPKM-3, dhKeyAgreement is a REQUIRED key establishment algorithm:
RFC 2025は、明らかにオプションのアルゴリズムとしてDHKEYAGREEMENT [PKCS-3]をリストしています。後で説明するように、RSAENCRYPTINGキー確立アルゴリズムは、この覚書で定義されている低インフラストラクチャセキュリティメカニズムには役に立ちません。したがって、SPKM-3では、dhkeyagreementは必須の重要な確立アルゴリズムです。
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
* One-Way Function for Subkey Derivation Algorithm (O-ALG)
* サブキー派生アルゴリズムの一元配置関数（o-alg）
RFC 2025 lists MD5 as a mandatory algorithm. Since MD5 has been found to have weaknesses when used as a hash [Dobbertin], id-sha1 is a MANDATORY O-ALG in SPKM-3:
RFC 2025は、MD5を必須アルゴリズムとしてリストします。Hash [dobbertin]として使用するとMD5が弱点を持つことがわかっているため、ID-Sha1はSPKM-3の必須のO-ALGです。
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26
}
The reference for the algorithm OID of id-sha1 is [RFC2437]. The reference for SHA-1 algorithm corresponding to id-sha1 is [FIPS].
ID-Sha1のアルゴリズムOIDの参照は[RFC2437]です。ID-Sha1に対応するSHA-1アルゴリズムの参照は[FIPS]です。
md5WithRSAEncryption The md5WithRSAEncryption integrity algorithm is listed in [RFC2025] as mandatory. Due to intellectual property considerations [RSA-IP], SPKM-3 implementations cannot be required to implement it. However, given the proliferation of certificates using RSA public keys, md5WithRSAEncryption is strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to leverage existing public key infrastructure will be limited.
md5withrsaencryption md5withrsaencryption整合性アルゴリズムは、必須として[rfc2025]にリストされています。知的財産の考慮事項[RSA-IP]により、SPKM-3の実装を実装する必要はありません。ただし、RSAパブリックキーを使用した証明書の拡散を考えると、MD5WithRSaEcryptionを強くお勧めします。それ以外の場合、Lipkeyが既存の公開キーインフラストラクチャを活用する機会は制限されます。
sha1WithRSAEncryption For reasons similar to that for md5WithRSAEncryption, sha1WithRSAEncryption is a RECOMMENDED algorithm. The sha1WithRSAEncryption algorithm is listed in addition to md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm [Dobbertin]. The OID for sha1WithRSAEncryption is:
sha1withrsaencryption md5withrsaencryptionと同様の理由で、sha1withrsaencryptionが推奨されるアルゴリズムです。Sha1withrsaencryptionアルゴリズムは、md5ハッシュアルゴリズム[ドブベルティン]の弱点により、md5withrsaencryptionに加えてリストされています。sha1withrsaencryptionのoidは次のとおりです。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5
}
The reference for the algorithm OID and description of sha1WithRSAEncryption is [RFC2437].
アルゴリズムoidの参照とsha1withrsaencryptionの説明は[RFC2437]です。
RFC 2025 sets up a context with an initiator first token (REQ-TOKEN), a target reply (REP-TI-TOKEN), and finally an initiator second token (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used. LIPKEY has certain requirements on the contents of the REQ-TOKEN and REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different from RFC 2025's SPKM-1 tokens.
RFC 2025は、イニシエーターの最初のトークン（REQトークン）、ターゲット返信（Rep-Ti-Token）、そして最後にイニシエーターセカンドトークン（Rep-It-Token）を使用してコンテキストを設定し、ターゲットの返信に返信します。Lipkeyは一方的な認証でSPKM-3を使用するため、Rep-It-Tokenは使用されません。Lipkeyには、Req-TokenとRep-Ti-Tokenの内容に関する特定の要件がありますが、SPKM-3トークンの構文はRFC 2025のSPKM-1トークンと違いはありません。
If the SPKM-3 initiator cannot calculate a req-integrity field due to the lack of a target certificate, it MUST use the NULL-MAC I-ALG described earlier in this memorandum. This will produce a zero length bit string in the Integrity field.
SPKM-3イニシエーターが、ターゲット証明書がないためにREQ積分フィールドを計算できない場合、この覚書で前述したnull-mac i-algを使用する必要があります。これにより、整合性フィールドにゼロの長さビット文字列が生成されます。
Because RFC 2025 requires that the RSAEncryption K-ALG be present, SPKM-1 must be able to map the target (targ-name) to its public key certificate, and thus SPKM can use the RSAEncryption algorithm to fill in the key-estb-req field. Because LIPKEY assumes a low infrastructure deployment, SPKM-3 MUST be prepared to be unable to map the targ-name field of the Req-contents field. This is a contradiction which is resolved by requiring SPKM-3 to support the dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries to map the target to a certificate, and succeeds, it is free to use the RSAEncryption K-ALG algorithm. It is also free to use an algID other than NULL-MAC in the REQ-TOKEN type.
RFC 2025では、RsaEcryption k-algが存在することを必要とするため、SPKM-1はターゲット（TARG-NAME）を公開鍵証明書にマッピングできる必要があります。Reqフィールド。Lipkeyは低いインフラストラクチャの展開を想定しているため、SPKM-3は、ReqコンテンツフィールドのTarg-Nameフィールドをマッピングできないように準備する必要があります。これは、SPKM-3にdhkeyagreementアルゴリズムをサポートすることを要求することによって解決される矛盾です。SPKM-3の実装がターゲットを証明書にマッピングしようとし、成功した場合、RsaEcryption k-algアルゴリズムを自由に使用できることに注意してください。また、reqトークンタイプでnull-mac以外のアルギッドを自由に使用できます。
SPKM-3 implementations MUST set the target-certif-data-required bit to 1 if the only K-ALG in the key-estb-set field of Req-contents is dhKeyAgreement. This would normally occur if the SPKM-3 implementation cannot resolve the target name to a certificate.
SPKM-3の実装は、reqコンテンツのキーエストセットフィールドの唯一のk-algがdhkeyagreementである場合、ターゲット-certif-dataリクイアドビットを1に設定する必要があります。これは通常、SPKM-3の実装がターゲット名を証明書に解決できない場合に発生します。
If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.
SPKM-3の実装がCAST5CBCよりも弱いアルゴリズムをサポートする場合、ターゲットがより強力なアルゴリズムをネゴシエートするように促すために、より弱いアルゴリズムの前にCAST5CBCをリストする必要があります。
Because the initiator will be anonymous (at the SPKM-3 level) and will not have a certificate for itself, the initiator cannot use an integrity algorithm that supports non-repudiation; it must use a MAC algorithm. If the SPKM-3 implementation supports an algorithm weaker than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.
イニシエーターは（SPKM-3レベルで）匿名であり、それ自体の証明書を持っていないため、イニシエーターは非繰り返しをサポートする整合性アルゴリズムを使用できません。Macアルゴリズムを使用する必要があります。SPKM-3の実装がHMAC-MD5よりも弱いアルゴリズムをサポートする場合、HMAC-MD5をより弱いアルゴリズムの前にリストする必要があります。
With the previously described requirements on REQ-TOKEN, the contents of SPKM-3's REP-TI-TOKEN can for the most part be derived from the specification in RFC 2025. The exceptions are the algId and rep-ti-integ fields.
Req-Tokenに関する以前に説明された要件により、SPKM-3のRep-Ti-Tokenの内容は、ほとんどの場合、RFC 2025の仕様から導き出すことができます。
The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or sha1WithRSAEncryption.
SPKM-3ターゲットは、null-mac i-algを使用してはなりません。id-dsa-with-sha1、md5withrsaencryption、またはsha1withrsaencryptionなどの署名アルゴリズムを使用する必要があります。
If the req-token has an algId of NULL-MAC, then the target MUST compute the rep-ti-integ on the concatenation of the req-contents and rep-ti-contents.
reqトークンにnull-macのアルギッドがある場合、ターゲットは、reqコンテンツとrep-ti含有量の連結に関するrep-ti-integを計算する必要があります。
The SPKM-3 initiator and target negotiate the set of algorithms they mutually support, using the procedure defined in Section 5.2 of RFC 2025. If a QOP of zero is specified, then the initiator and target will use the first C-ALG (privacy), and I-ALG (integrity) algorithms negotiated.
SPKM-3イニシエーターとターゲットは、RFC 2025のセクション5.2で定義されている手順を使用して、相互にサポートするアルゴリズムのセットを交渉します。、およびi-alg（整合性）アルゴリズムがネゴシエートされました。
SPKM breaks the QOP into several fields, as reproduced here from Section 5.2 of RFC 2025:
SPKMは、RFC 2025のセクション5.2からここで再現されているように、QOPをいくつかのフィールドに分割します。
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
-------------------------------|-------------------------------
| TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
-------------------------------|-------------------------------
The MA subfields enumerate mechanism-defined algorithms. Since this memorandum introduces a new mechanism, SPKM-3, within the SPKM family, it is appropriate to add algorithms to the MA subfields of the respective Confidentiality and Integrity fields.
MAサブフィールドは、メカニズム定義のアルゴリズムを列挙します。この覚書は、SPKMファミリー内で新しいメカニズムであるSPKM-3を導入しているため、それぞれの機密性と完全性分野のMAサブフィールドにアルゴリズムを追加することが適切です。
The complete set of Confidentiality MA algorithms is thus:
したがって、機密性の完全なセットMAアルゴリズムは次のとおりです。
0001 (1) = DES-CBC 0010 (2) = cast5CBC
0001（1）= DES-CBC 0010（2）= CAST5CBC
Where "0001" and "0010" are in base 2. An SPKM peer that negotiates a confidentiality MA algorithm value of "0010" MUST use a 128 bit key, i.e. set the keyLength values in the cast5CBC Parameters to 128 bits.
ここで、「0001」と「0010」がベース2にあります。「0010」という機密性を交渉するSPKMピアは、128ビットキーを使用する必要があります。
The complete set of Integrity MA algorithms is thus:
したがって、整合性MAアルゴリズムの完全なセットは次のとおりです。
0001 (1) = md5WithRSAEncryption 0010 (2) = DES-MAC 0011 (3) = id-dsa-with-sha1 0100 (4) = HMAC-MD5 0101 (5) = sha1WithRSAEncryption
0001（1）= md5withrsaencryption 0010（2）= des-mac 0011（3）= id-dsa-with-sha1 0100（4）= hmac-md5 0101（5）= sha1withrsaencryption
Where "0001" through "0101" are in base 2.
ここで、「0001」から「0101」からベース2にあります。
Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does not impair SPKM-1 and SPKM-2 backward compatibility because, as noted previously, SPKM negotiates algorithms. An older SPKM-1 or SPKM-2 that does not recognize MA values for cast5CBC, id-dsa-with-sha1, HMAC-MD5, or sha1WithRSAEncryption will not select them.
上記の方法でSPKM-1およびSPKM-2に上記の方法で、CAST5CBC、ID-DSA-with-sha1、hmac-md5、およびsha1withrsaencryptionのサポートを追加してください。アルゴリズムを交渉します。CAST5CBC、ID-DSA-with-sha1、hmac-md5、またはsha1withrsaencryptionのMA値を認識しない古いSPKM-1またはSPKM-2はそれらを選択しません。
LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism that the application uses is LIPKEY, LIPKEY will wrap some of the SPKM-3 tokens with LIPKEY prefixes. The exact definition of the tokens is described later in this memorandum.
LipkeyはSPKM-3を呼び出してSPKMトークンを生成します。アプリケーションが使用するメカニズムはLipkeyであるため、LipkeyはSPKM-3トークンの一部をLipkeyプレフィックスでラップします。トークンの正確な定義については、この覚書で後で説明します。
The initiator uses GSS_Import_name to import the target's name, typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE name type. Ultimately, the output of GSS_Import_name will apply to an SPKM-3 mechanism type because a LIPKEY target is an SPKM-3 target.
イニシエーターはGSS_IMPORT_NAMEを使用して、ターゲットの名前をインポートしますが、通常ではありませんが、GSS_C_NT_HOSTBASED_SERVICE名タイプを使用します。最終的に、LipkeyターゲットはSPKM-3ターゲットであるため、GSS_IMPORT_NAMEの出力はSPKM-3メカニズムタイプに適用されます。
The initiator calls GSS_Acquire_cred. The credentials that are acquired are LIPKEY credentials, a user name and password. How the user name and password is acquired is dependent upon the operating environment. A application that invokes GSS_Acquire_cred() while the application's user has a graphical user interface running might trigger the appearance of a pop up window that prompts for the information. A application embedded into the operating system, such as an NFS [Sandberg] client implemented as a native file system might broadcast a message to the user's terminals telling him to invoke a command that prompts for the information.
イニシエーターはGSS_ACQUIRE_CREDを呼び出します。取得された資格情報は、Lipkey資格、ユーザー名、パスワードです。ユーザー名とパスワードの取得方法は、動作環境に依存します。GSS_ACQUIRE_CRED（）を呼び出すアプリケーションは、アプリケーションのユーザーにグラフィカルなユーザーインターフェイスを実行している間、情報をプロンプトするポップアップウィンドウの外観をトリガーする場合があります。ネイティブファイルシステムとして実装されたNFS [Sandberg]クライアントなどのオペレーティングシステムに組み込まれたアプリケーションは、情報をプロンプトするコマンドを呼び出すように彼にメッセージをブロードキャストする可能性があります。
Because the credentials will not be used until GSS_Init_sec_context is called, the LIPKEY implementation will need to safeguard the credentials. If this is a problem, the implementation may instead defer actual acquisition of the user name and password until GSS_init_sec_context is ready to send the user name and password to the target. In that event, the output_cred_handle argument of GSS_Acquire_cred would simply be a reference that mapped to the principal corresponding to the desired_name argument. A subsequent GSS_Init_sec_context call would consider the mapping of claimant_cred_handle to principal when it acquires the user name and password. For example, the aforementioned pop up window might fill in the user name portion of the dialog with a default value that maps to the principal referred to in claimant_cred_handle.
資格情報はGSS_INIT_SEC_CONTEXTが呼び出されるまで使用されないため、Lipkeyの実装は資格情報を保護する必要があります。これが問題の場合、実装は、GSS_INIT_SEC_CONTEXTがユーザー名とパスワードをターゲットに送信する準備ができるまで、ユーザー名とパスワードの実際の取得を延期する場合があります。その場合、gss_acquire_credのoutput_cred_handle引数は、単に希望の_name引数に対応するプリンシパルにマッピングされた参照です。その後のGSS_INIT_SEC_CONTEXT呼び出しでは、ユーザー名とパスワードを取得したときに請求者のマッピングをプリンシパルに考慮します。たとえば、前述のポップアップウィンドウは、ダイアログのユーザー名の部分に、請求者の請求者_cred_handleで言及されているプリンシパルにマップするデフォルト値で記入する場合があります。
When a program invokes GSS_Init_sec_context on the LIPKEY mechanism type, if the context handle is NULL, the LIPKEY mechanism will in turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented according to the requirements described previously. This call to SPKM-3 MUST have the following attributes:
プログラムがLipkeyメカニズムタイプにGSS_INIT_SEC_CONTEXTを呼び出すと、コンテキストハンドルがnullの場合、リプキーメカニズムは、前述の要件に従って実装されたSPKM-3メカニズムにGSS_INIT_SEC_CONTEXTを呼び出します。SPKM-3へのこの呼び出しには、次の属性が必要です。
* claimant_cred_handle is NULL
* 請求者_cred_handleはnullです
* mutual_req_flag is FALSE
* untumor_req_flagはfalseです
* anon_req_flag is TRUE
* anon_req_flagは本当です
* input_token is NULL
* input_tokenはnullです
* mech_type is the OID of the SPKM-3 mechanism
* mech_typeは、SPKM-3メカニズムのOIDです
Keep in mind the above attributes are in the GSS_Init_sec_context call from the LIPKEY mechanism down to the SPKM-3 mechanism. There are no special restrictions placed on the application invoking LIPKEY's GSS_Init_sec_context routine. All other arguments are derived from the LIPKEY GSS_Init_sec_context arguments.
上記の属性は、LipkeyメカニズムからSPKM-3メカニズムまでのGSS_INIT_SEC_CONTEXTコールにあることに留意してください。LipkeyのGSS_INIT_SEC_CONTEXTルーチンを呼び出すアプリケーションに特別な制限はありません。他のすべての引数は、Lipkey GSS_INIT_SEC_CONTEXT引数から派生しています。
The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3 context handle. The remainder of the description of the LIPKEY GSS_Init_sec_context call depends on whether the caller of the LIPKEY GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE.
SPKM-3 GSS_INIT_SEC_CONTEXTへの呼び出しは、SPKM-3コンテキストハンドルを作成します。Lipkey GSS_INIT_SEC_CONTEXTコールの説明の残りの部分は、LIPKEY GSS_INIT_SEC_CONTEXTの発信者がANON_REQ_FLAGをTrueまたはfalsに設定するかどうかによって異なります。
If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to TRUE, it MUST return to the LIPKEY caller all the outputs from the SPKM-3 GSS_Init_sec_context call, including the output_context_handle, output_token, and mech_type. In this way, LIPKEY now "gets out of the way" of GSS-API processing between the application and SPKM-3, because nothing in the returned outputs relates to LIPKEY. This is necessary, because LIPKEY context tokens do not have provision for specifying anonymous initiators. This is because SPKM-3 is sufficient for purpose of supporting anonymous initiators in a low infrastructure environment.
Lipkeyのgss_init_sec_contextの発信者がanon_req_flagをtrueに設定する場合、output_context_handle、output_token、mech_typeを含む、spkm-3 gss_init_sec_contextコールからのすべての出力をリップキーコーラーに返す必要があります。このようにして、リプキーはアプリケーションとSPKM-3の間のGSS-API処理の「邪魔にならない」ようになりました。これは、返された出力の何もLipkeyに関連していないためです。これは、リプキーコンテキストトークンには匿名イニシエーターを指定するための規定がないため、これが必要です。これは、SPKM-3が、低インフラストラクチャ環境で匿名イニシエーターをサポートするために十分であるためです。
Clearly, when the LIPKEY caller desires anonymous authentication, LIPKEY does not add any value, but it is simpler to support the feature, than to insist the caller directly use SPKM-3.
明らかに、Lipkey発信者が匿名認証を望む場合、Lipkeyは価値を追加しませんが、発信者がSPKM-3を直接使用することを主張するよりも、機能をサポートする方が簡単です。
If all goes well, the caller of LIPKEY will be returned a major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the response token from the target, and directly invokes the SPKM-3 GSS_Init_sec_context. Upon return, the major_status should be GSS_S_COMPLETE.
すべてがうまくいけば、Lipkeyの発信者はSPKM-3を介してGSS_S_CONTINUE_NEEDEDのMajor_Statusを返します。したがって、Lipkeyの発信者はoutput_tokenをターゲットに送信します。Lipkeyの発信者は、ターゲットから応答トークンを受け取り、SPKM-3 GSS_INIT_SEC_CONTEXTを直接呼び出します。帰国後、Major_StatusはGSS_S_COMPLETEである必要があります。
The LIPKEY mechanism will need to allocate a context handle for itself, and record in the LIPKEY context handle the SPKM-3 context handle that was returned in the output_context_handle parameter from the call to the SPKM-3 GSS_Init_sec_context routine. The LIPKEY GSS_Init_sec_context routine will return in output_context_handle the LIPKEY context handle, and in mech_type, the LIPKEY mechanism type. The output_token is as defined later in this memorandum, in the subsection entitled "Context Tokens Prior to SPKM-3 Context Establishment." All the other returned outputs will be those that the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all went well, the SPKM-3 mechanism will have returned a major_status of GSS_S_CONTINUE_NEEDED.
リップキーメカニズムは、それ自体にコンテキストハンドルを割り当てる必要があり、リップキーコンテキストで記録して、spkm-3 gss_init_sec_contextルーチンに呼び出しからoutput_context_handleパラメーターで返されたSPKM-3コンテキストハンドルをハンドルします。Lipkey GSS_INIT_SEC_CONTEXTルーチンは、output_context_handleでリプキーコンテキストハンドルとmech_typeでリップキーメカニズムタイプで返されます。output_tokenは、この覚書の後半で、「SPKM-3コンテキスト確立の前のコンテキストトークン」と題されたサブセクションで定義されています。他のすべての返された出力は、SPKM-3 GSS_INIT_SEC_CONTEXTルーチンがLipkeyに返されたものです。すべてがうまくいけば、SPKM-3メカニズムはGSS_S_Continue_neededのMajor_statusを返しました。
The caller of the LIPKEY GSS_Init_sec_context routine will see a major_status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the target's response token, and invokes the LIPKEY GSS_Init_sec_context routine for a second time. LIPKEY then invokes the SPKM-3 GSS_Init_sec_context for a second time and upon return, the major_status should be GSS_S_COMPLETE.
Lipkey GSS_INIT_SEC_CONTEXTルーチンの発信者は、GSS_S_S_CONTINUE_NEEDEDのMajoy_Statusが表示されるため、Lipkeyの発信者はoutput_tokenをターゲットに送信します。Lipkeyの発信者は、ターゲットの応答トークンを受け取り、Lipkey GSS_INIT_SEC_CONTEXTルーチンを2回目の呼び出します。Lipkeyはその後、SPKM-3 GSS_INIT_SEC_CONTEXTを2回目で呼び出し、戻ってきた後、Major_StatusはGSS_S_COMPLETEでなければなりません。
While SPKM-3's context establishment is now complete, LIPKEY's context establishment is not yet complete, because the initiator must send to the target the user name and password that were passed to it via the claimant_cred_handle on the first call to the LIPKEY GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3 context handle as the input to GSS_Wrap (with conf_req_flag set to TRUE) to encrypt what the claimant_cred_handle refers to (user name and password), and returns that as the output_token to the caller of LIPKEY (provided the conf_state output from the call to SPKM-3's GSS_Wrap is TRUE), along with a major_status of GSS_S_CONTINUE_NEEDED.
SPKM-3のコンテキスト確立が完了するようになりましたが、Lipkey GSS_INIT_INIT_SEC_CONTEXTルーチンの最初の呼び出しで請求者の名前とパスワードをターゲットに送信する必要があります。Lipkeyは、確立されたSPKM-3コンテキストハンドルをGSS_WRAPへの入力として使用します（conf_req_flagがtrueに設定されています）を使用して、請求者_cred_handleが（ユーザー名とパスワード）を（ユーザー名とパスワード）と暗号化し、output_tokenとしてreppeyの発信者に（conf_stateの発信者に返す）SPKM-3のGSS_WRAPへの呼び出しからの出力は、GSS_S_CONTINUE_NEEDEDのMajoy_Statusとともに、True）です。
The caller of LIPKEY sends its second context establishment token to the target, and waits for a token provided by the target's GSS_Accept_sec_context routine. The target's LIPKEY GSS_Accept_sec_context routine invokes the SPKM-3 GSS_Unwrap routine on the token, and validates the user name and password. The target then invokes SPKM-3's GSS_Wrap routine on a boolean indicating whether or not the user name and password were accepted, and returns the output_message result from GSS_Wrap as the output_token result for GSS_Accept_sec_context.
Lipkeyの発信者は、2番目のコンテキスト確立トークンをターゲットに送信し、ターゲットのGSS_ACCEPT_SEC_CONTEXTルーチンによって提供されるトークンを待ちます。ターゲットのLipkey GSS_ACCEPT_SEC_CONTEXTルーチンは、トークンにSPKM-3 GSS_UNWRAPルーチンを呼び出し、ユーザー名とパスワードを検証します。次に、ターゲットは、ユーザー名とパスワードが受け入れられたかどうかを示すブール値にSPKM-3のGSS_WRAPルーチンを呼び出し、GSS_ACCEPT_SEC_CONTEXTの出力_TOKEN結果としてGSS_WRAPから出力_Messageの結果を返します。
The caller of LIPKEY receives the target's response token, and passes this via the input_token parameter to the LIPKEY GSS_Init_sec_context routine. LIPKEY then invokes GSS_Unwrap to get the boolean acceptance indication, and maps this to a major_status of either GSS_S_COMPLETE indicating successful (the boolean was TRUE) and completed LIPKEY context establishment, or GSS_S_FAILURE, indicating that context establishment failed. GSS_S_CONTINUE_NEEDED will not be returned.
Lipkeyの発信者は、ターゲットの応答トークンを受信し、input_tokenパラメーターを介してLipkey GSS_INIT_SEC_CONTEXTルーチンにこれを渡します。その後、LipkeyはGSS_UNWRAPを呼び出してブールの受け入れ兆候を取得し、これをGSS_S_COMPLETEのいずれかのMajor_statusにマッピングし、成功したことを示し（ブール波が真実でした）、リプキーコンテキスト確立を完了し、GSS_S_FAILUREを完了し、コンテキストの確立が失敗したことを示しています。gss_s_continue_neededは返されません。
Note that the mutual_req_flag parameter is ignored because unilateral authentication is impossible. The initiator must authenticate the target via SPKM-3 in order to create a secure channel to transmit the user name and password. The target must authenticate the initiator when it receives the user name and password.
一方的な認証が不可能であるため、相互_req_flagパラメーターは無視されていることに注意してください。イニシエーターは、ユーザー名とパスワードを送信する安全なチャネルを作成するために、SPKM-3を介してターゲットを認証する必要があります。ターゲットは、ユーザー名とパスワードを受信したときにイニシエーターを認証する必要があります。
The SPKM-3 context remains established while the LIPKEY context is established. If the SPKM-3 context expires before the LIPKEY context is destroyed, the LIPKEY implementation should expire the LIPKEY context and return the appropriate error on the next GSS-API operation.
SPKM-3コンテキストは、リプキーコンテキストが確立されている間、確立されたままです。Lipkeyコンテキストが破壊される前にSPKM-3コンテキストが期限切れになった場合、リプキーの実装はリプキーコンテキストを期限切れにし、次のGSS-API操作で適切なエラーを返す必要があります。
For other operations, the LIPKEY context acts as a pass through to the SPKM-3 context. Operations that affect or inquire context state, such as GSS_Delete_sec_context, GSS_Export_sec_context, GSS_Import_sec_context, and GSS_Inquire_context will require a pass through to the SPKM-3 context and a state modification of the LIPKEY context.
他の操作の場合、LipkeyコンテキストはSPKM-3コンテキストへのパスを通過します。gss_delete_sec_context、gss_export_sec_context、gss_import_sec_context、gss_inquire_contextなどのコンテキスト状態に影響または調査する操作には、spkm-3コンテキストとリプキーのコンテキストの状態修正が必要です。
As with the initiator, the imported name will be that of the target.
イニシエーターと同様に、インポートされた名前はターゲットの名前になります。
The target calls the LIPKEY GSS_Acquire_cred routine to get a credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred routine. The desired_name is the output_name from GSS_Import_name.
ターゲットは、Lipkey GSS_ACQUIRE_CREDルーチンを呼び出して、SPKM-3 GSS_ACQUIRE_CREDルーチンを介して、SPKM-3ターゲットの資格情報を取得します。希望_nameはgss_import_nameのoutput_nameです。
When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism type, if the context handle is NULL, the LIPKEY mechanism will in turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented according the requirements described previously. This call to SPKM-3 is no different than what one would expect for a layered call to GSS_Accept_sec_context.
プログラムがLipkeyメカニズムタイプにGSS_ACCEPT_SEC_CONTEXTを呼び出すと、コンテキストハンドルがNULLの場合、リプキーメカニズムは、前述の要件に従って実装されたSPKM-3メカニズムのGSS_ACCEPT_SEC_CONTEXTを順番に呼び出します。SPKM-3へのこの呼び出しは、gss_accept_sec_contextへの階層化された呼び出しに対して期待されるものと違いはありません。
If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call returns the output_token to the caller, but with a major_status of GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected to send the user name and password.
If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call returns the output_token to the caller, but with a major_status of GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected to send the user name and password.
Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token the target receives will contain the user name and password, wrapped by the output of an SPKM-3 GSS_Wrap call. The target invokes the LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3 GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then compares the user name and password with its user name name and password database. If the initiator's user name and password are valid, GSS_S_COMPLETE is returned to the caller. Otherwise GSS_S_FAILURE is returned. In either case, an output_token - equal to the output_message result from an SPKM-3 GSS_Wrap call on a boolean value - is returned to the caller. The boolean value is set to TRUE if the the user name and password were valid, FALSE otherwise. The target expects no more context establishment tokens from caller.
SPKM-3コンテキストがGSS_S_COMPLETE状態になると、ターゲットが受信する次のトークンには、SPKM-3 GSS_WRAP呼び出しの出力によってラップされたユーザー名とパスワードが含まれます。ターゲットは、Lipkey GSS_ACCEPT_SEC_CONTEXTを呼び出し、SPKM-3 GSS_UNWRAPルーチンを呼び出します。Lipkey GSS_ACCEPT_SEC_CONTEXTルーチンは、ユーザー名とパスワードをユーザー名とパスワードデータベースと比較します。イニシエーターのユーザー名とパスワードが有効な場合、gss_s_completeが発信者に返されます。それ以外の場合は、GSS_S_FAILUREが返されます。どちらの場合でも、output_token -OUTPUT_MESSAGEの結果に等しいSPKM -3 GSS_WRAPコールがブール値を呼び出します - は、発信者に返されます。ブール値は、ユーザー名とパスワードが有効である場合にtrueに設定されます。ターゲットは、発信者からのコンテキスト確立トークンを期待していません。
lipkey OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)lipkey(9)}
LIPKEY uses only the mechanism independent name types defined in RFC 2078. All the name types defined in RFC 2078 are REQUIRED.
Lipkeyは、RFC 2078で定義されたメカニズム独立した名前タイプのみを使用します。RFC2078で定義されたすべての名前タイプが必要です。
GSS-API defines the context tokens as:
GSS-APIは、コンテキストトークンを次のように定義します。
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
The contents of the innerContextToken depend on whether the SPKM-3 context is established or not.
InnerContextTokenの内容は、SPKM-3コンテキストが確立されているかどうかに依存します。
In a LIPKEY InitialContextToken, thisMech will be the Object identifier for LIPKEY. However, as long as LIPKEY has not established the SPKM-3 mechanism, the innerContextToken for both the InitialContextToken and the SubsequentContextToken will be the output of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context. So the LIPKEY innerContextToken would be either:
Lipkey initialContextTokenでは、このメックはリップキーのオブジェクト識別子になります。ただし、LipkeyがSPKM-3メカニズムを確立していない限り、InitialContextTokenとその後のContextTokenの両方のInnerContextTokenは、SPKM-3 GSS_INIT_SEC_CONTEXTまたはGSS_ACCEPT_SEC_CONTEXTの出力になります。したがって、リップキーインナーコントテクストトークンは次のとおりです。
* An InitialContextToken, with thisMech set to the object identifier for SPKM-3, with innerContextToken defined to be an SPKMInnerContextToken, as defined in RFC 2025.
* このメックがSPKM-3のオブジェクト識別子に設定されたInitialContextTokenは、RFC 2025で定義されているように、SPKMinnerContextTokenであると定義されています。
* A SubsequentContextToken, with innerContextToken defined to be SPKMInnerContextToken
* innerContextTokenがspkminnercontexttokenであると定義された後続のコントテクストトークン
Once the SPKM-3 context is established, there is just one token sent from the initiator to the target, and one token returned to initiator.
SPKM-3コンテキストが確立されると、イニシエーターからターゲットに送信されたトークンが1つしかなく、1つのトークンがイニシエーターに戻りました。
The LIPKEY initiator generates a token that is the the result of a GSS_Wrap (conf_req is set to TRUE) of a user name and password by the SPKM-3 context. The input_message argument of GSS_Wrap refers to an instance of the UserName-Password type defined below:
Lipkey Initiatorは、SPKM-3コンテキストによってユーザー名とパスワードのGSS_WRAP（conf_reqがtrueに設定されている）の結果であるトークンを生成します。gss_wrapのinput_message引数は、以下に定義されているユーザー名パスワードタイプのインスタンスを指します。
UserName-Password ::= SEQUENCE {
user-name OCTET STRING,
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
password OCTET STRING
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
}
The target validates the user name and password token from the initiator, and generates a response token that is the output_message result of an SPKM-3 GSS_Wrap (conf_req may or may not be set to TRUE) call on an indication of validation success. The input_message argument of GSS_Wrap refers to an instance of the Valid-UNP type defined below:
ターゲットは、イニシエーターからのユーザー名とパスワードトークンを検証し、検証の成功を示すために、SPKM-3 GSS_WRAP（conf_reqがTrueに設定されている場合と設定されない場合があります）のoutput_message結果である応答トークンを生成します。gss_wrapのinput_message引数は、以下に定義されている有効なUNPタイプのインスタンスを指します。
Valid-UNP ::= BOOLEAN
-- If TRUE, user name/password pair was valid.
RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required
sealedUserData ANY
As one can see, there are no mechanism independent prefixes in PerMSGToken or SealedMessage, and no explicit mechanism specific information. Since LIPKEY does not add any value to GSS_GetMIC and GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC and GSS_Wrap, LIPKEY's PerMsgToken and SealedMessage tokens are exactly what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce.
ご覧のとおり、PermsgtokenまたはSealedMessageには、独立したメカニズムの接頭辞はありません。明示的なメカニズム固有の情報はありません。Lipkeyは、spkm-3 gss_getmic and gss_wrapにメッセージを渡す以外に、GSS_getmicとgss_wrapに価値を追加しないため、LipkeyのPermsgtokenおよびSealedMessageトークンは、SPKM-3のGSS_GETMICおよびGSS_WRAPRUSが生成するものです。
LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3, does not interpret or alter the QOPs passed to the aforementioned routines or received from their complements, GSS_Unwrap, and GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3.
Lipkeyは、GSS_WRAPとGSS_GetMicのSPKM-3のパスを通過しているため、前述のルーチンに渡されたQOPS、または補数、GSS_UNWRAP、およびGSS_VERIFYMICから受け取ったQOPSを解釈または変更しません。したがって、LipkeyはSPKM-3と同じQOPSセットをサポートします。
LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so the risk in this approach is in how the target manages the password after it is done with it. The approach should be safe, provided the target clears the memory (primary and secondary, such as disk) buffers that contained the password, and any hash of the password immediately after it has validated the user's password.
Lipkeyは、128ビットCAST5CBCで暗号化されたクリアテキストパスワードを送信するため、このアプローチのリスクは、ターゲットがパスワードを実行した後にどのように管理するかにあります。ターゲットがパスワードを含むメモリ（ディスクなどのプライマリおよびセカンダリ）バッファーと、ユーザーのパスワードを検証した直後にパスワードのハッシュをクリアすると、アプローチが安全である必要があります。
The initiator must have a list of trusted Certification Authorities in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's context reply token. If it encounters a certificate signed by an unknown and/or untrusted certificate authority, the initiator MUST NOT silently accept the certificate. If it does wish to accept the certificate, it MUST get confirmation from the user running the application that is using GSS-API.
イニシエーターは、SPKM-3ターゲットのコンテキスト応答トークンでチェックサム（rep-ti-integ）を検証するために、信頼できる認証当局のリストを持っている必要があります。不明および/または信頼されていない証明書当局によって署名された証明書に遭遇した場合、イニシエーターは証明書を静かに受け入れてはなりません。証明書を受け入れたい場合は、GSS-APIを使用しているアプリケーションを実行しているユーザーから確認を取得する必要があります。
While the MD5 hash algorithm has been found to have weaknesses [Dobbertin], the weaknesses do not impact the security of HMAC-MD5 [Dobbertin].
MD5ハッシュアルゴリズムには弱点があることがわかっていますが[Dobbertin]、弱点はHMAC-MD5 [Dobbertin]のセキュリティに影響しません。
The cast5CBC encryption algorithm is relatively new compared to established algorithms like triple DES, and RC4. Nonetheless, the choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable. The cast5CBC algorithm is a 128 bit algorithm that the 256 bit cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm was judged by the U.S. National Institute of Standards and Technology (NIST) to have no known major or minor "security gaps," and to have a "high security margin" [AES]. NIST did note some vulnerabilities related to smart card implementations, but many other algorithms NIST analyzed shared the vulnerabilities, and in any case, LIPKEY is by definition not aimed at smart cards.
CAST5CBC暗号化アルゴリズムは、Triple DESやRC4などの確立されたアルゴリズムと比較して比較的新しいものです。それにもかかわらず、SPKM-3の必須C-AlgとしてのCAST5CBCの選択をお勧めします。CAST5CBCアルゴリズムは、256ビットCAST6CBC [RFC2612]アルゴリズムが基づいている128ビットアルゴリズムです。CAST6CBCアルゴリズムは、米国国立標準技術研究所（NIST）によって、メジャーまたはマイナーな「セキュリティギャップ」が知られていないと判断され、「セキュリティマージンが高い」[AES]がありました。NISTはスマートカードの実装に関連するいくつかの脆弱性に注意しましたが、他の多くのアルゴリズムNIST分析が脆弱性を共有し、いずれにせよ、Lipkeyは定義上、スマートカードを目指していません。
References
参考文献
[AES] Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti, J., Roback, E. (Undated, but no later than 1999). "Status Report on the First Round of the Development of the Advanced Encryption Standard." http://csrc.nist.gov/encryption/aes/round1/r1report.htm
[AES] Nechvatal、J.、Barker、E.、Dodson、D.、Dworkin、M.、Foti、J.、Roback、E。「高度な暗号化標準の開発の第1ラウンドに関するステータスレポート。」http://csrc.nist.gov/encryption/aes/round1/r1report.htm
[CCITT] CCITT (1988). "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)."
[Ccitt] Ccitt（1988）。「推奨X.208：抽象的構文表記1（asn.1）の仕様。」
[Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent Attack," RSA Laboratories' CryptoBytes, Volume 2, Number 2. ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[Dobbertin] Dobbertin、H。（1996）。「最近の攻撃後のMD5のステータス」、RSA Laboratories 'Cryptobytes、Volume 2、Number2。ftp：//ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[EFF] Electronic Frontier Foundation, John Gilmore (Editor) (1998). "Cracking Des: Secrets of Encryption Research, Wiretap Politics & Chip Design," O'Reilly & Associates, ISBN 1565925203.
[EFF] Electronic Frontier Foundation、John Gilmore（編集者）（1998）。「クラッキングデス：暗号化研究の秘密、盗聴政治＆チップデザイン」、O'Reilly＆Associates、ISBN 1565925203。
[FIPS] National Institute of Standards and Technology (1995). "Secure Hash Standard" (SHA-1). http://www.itl.nist.gov/fipspubs/fip180-1.htm
[FIPS]国立標準技術研究所（1995）。「セキュアハッシュ標準」（SHA-1）。http://www.itl.nist.gov/fipspubs/fip180-1.htm
[IANA] Internet Assigned Numbers Authority (1999). "Network Management Parameters." http://www.isi.edu/in-notes/iana/assignments/smi-numbers
[IANA]インターネットが割り当てられた番号局（1999）。「ネットワーク管理パラメーター。」http://www.isi.edu/in-notes/iana/assignments/smi-numbers
[PKCS-3] RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-Agreement Standard, Version 1.4." ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
[PKCS-3] RSA Laboratories（1993）。「PKCS＃3：Diffie-Hellman Key-Agreement Standard、バージョン1.4。」ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", Work in Progress.
[Pkix] Housley、R.、Ford、W.、Polk、W.、Solo、D。、「インターネットX.509公開キーインフラストラクチャ証明書とCRLプロファイル」、進行中の作業。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[RFC1831] Srinivasan、R。、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832] Srinivasan、R。、「XDR：外部データ表現標準」、RFC 1832、1995年8月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964] Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025] Adams、C。、「シンプルなパブリックキーGSS-APIメカニズム（SPKM）」、RFC 2025、1996年10月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078] Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス、バージョン2」、RFC 2078、1997年1月。
[RFC2104] Krawczyk, H, Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144] Adams、C。、「The Cast-128暗号化アルゴリズム」、RFC 2144、1997年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[RFC2437] Kaliski、B。and J. Staddon、「PKCS＃1：RSA暗号仕様バージョン2.0」、RFC 2437、1998年10月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459] Housley、R.、Ford、W.、Polk、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書とCRLプロファイル」、RFC 2459、1999年1月。
[RFC2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, June 1999.
[RFC2612] Adams、C。およびJ. Gilchrist、「The Cast-256暗号化アルゴリズム」、RFC 2612、1999年6月。
[RSA-IP] All statements received by the IETF Secretariat are places on-line in http://www.ietf.org/ipr.html. Please check this web page to see any IPR information received about this and other technology.
[RSA-IP] IETF事務局が受け取ったすべてのステートメントは、http：//www.ietf.org/ipr.htmlのオンラインでの場所です。このWebページをチェックして、このテクノロジーやその他のテクノロジーについて受け取ったIPR情報を確認してください。
[Sandberg] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, B. (1985). "Design and Implementation of the Sun Network Filesystem," Proceedings of the 1985 Summer USENIX Technical Conference.
[Sandberg] Sandberg、R.、Goldberg、D.、Kleiman、S.、Walsh、D.、Lyon、B。（1985）。「サンネットワークファイルシステムの設計と実装」、1985年の夏のUSENIX技術会議の議事録。
[Schneier] Schneier, B. (1996). "Applied Cryptography," John Wiley & Sons, Inc., ISBN 0-471-11709-9.
[Schneier] Schneier、B。（1996）。「応用暗号化」、John Wiley＆Sons、Inc.、ISBN 0-471-11709-9。
[Young] Young, E.A. (1997). Collected timing results from the SSLeay source code distribution.
[ヤング]ヤング、E.A。（1997）。収集されたタイミングは、SSLEAYソースコードの分布から生じます。
Acknowledgments
謝辞
The author thanks and acknowledges:
著者は感謝し、認めます：
* Jack Kabat for his patient explanation of the intricacies of SPKM, excellent suggestions, and review comments.
* Jack Kabatは、SPKMの複雑さ、優れた提案、およびレビューコメントについての患者の説明について説明しました。
* Denis Pinkas for his review comments.
* 彼のレビューコメントのためのデニス・ピンカス。
* Carlisle Adams for his review comments.
* 彼のレビューコメントのためにカーライルアダムス。
* John Linn for his review comments.
* 彼のレビューコメントのためのジョン・リン。
* Martin Rex for his review comments.
* 彼のレビューコメントについてマーティン・レックス。
* This memorandum includes ASN.1 definitions for GSS-API tokens from RFC 2078, which was authored by John Linn.
* この覚書には、John Linnが執筆したRFC 2078のGSS-APIトークンのASN.1定義が含まれています。
* This memorandum includes ASN.1 definitions and other text from the SPKM definition in RFC 2025, which was authored by Carlisle Adams.
* この覚書には、RFC 2025のSPKM定義からのASN.1の定義とその他のテキストが含まれています。
Author's Address
著者の連絡先
Address comments related to this memorandum to:
この覚書に関連するコメントに対処してください。
ietf-cat-wg@lists.Stanford.EDU
ietf-cat-wg@lists.stanford.edu
Mike Eisler Zambeel 5565 Wilson Road Colorado Springs, CO 80919
マイクアイスラーザンベル5565ウィルソンロードコロラドスプリングス、コロラド州80919
Phone: 1-719-599-9026 EMail: mike@eisler.com
電話：1-719-599-9026メール：mike@eisler.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。