Network Working Group M. Eisler
Request for Comments: 2847 Zambeel
Category: Standards Track June 2000
LIPKEY - A Low Infrastructure Public Key Mechanism Using 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.
著作権（C）インターネット協会（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].
この覚書は、1つのパスワードを使用してクライアントを認証し、クライアントとサーバの間で安全なチャネルを供給するために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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]などのアプリケーションプロトコルと同様であるので、容易に上位層アプリケーションプロトコルをカプセル化層として実装されているTLSのようなプロトコルに噛合していません。 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メカニズムは、ケルベロス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 Serverで実行しますほとんどのオペレーティングシステムは、すでにネイティブのパスワードデータベースを持っているので、ネット追加のインフラストラクチャは、サーバ証明書と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と同じ機構型オブジェクト識別子（OID）を使用することを含む）SPKM-1の実装内でこれらの意味的な変更を実装することは可能であるが、変更のセットは、ここで互換性がだろう点に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は、RFC 2078のすべてのメカニズムの独立した名前の種類SPKM-3の実装をサポートする必要があります。
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に記載されている必要な鍵確立（K-ALG）、完全性（I-ALG）およびサブキー導出のための一方向関数（O-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-TOKENでの整合性値を計算するための目標のために、それは不可能です。だから我々は、ASN.1 [CCITT]構文にかかわらず、それに渡される入力の長さがゼロのビット列を返すヌル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.
作業中の[PKIX]廃止RFC 2459への作業中は、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イニシエータが証明書を持たないの結果は、コンテキストが確立されると、それはmd5WithRSAEncryption、ID-DSA-WITH-SHA1、またはsha1WithRSAEncryptionようなデジタル署名アルゴリズムを使用できないことです。代わりに、メッセージ認証コード（MAC）アルゴリズムが必要です。 [RFC2025]で推奨さDES-MACが指定されています。 56ビットDESのセキュリティは、[EFF]不十分であることが示されているので、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].
SHA1はMD5 [ヤング]の約半分の速度であるので、HMAC-SHA1アルゴリズムは必須SPKM-3 I-ALG MACありません。 MD5は、3つの暗号化アルゴリズム[ヤング]の最速よりも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:
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.
cast5CBCアルゴリズムのOIDおよび説明のための基準は、[RFC2144]です。パラメータのKEYLENGTHは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.
それはcast5CBCよりはるかに遅いので、トリプルDES（DES EDE3）アルゴリズムは必須SPKM-3 C-ALGはありません。 SSLeayのコードを使用してのPentium Proの200メガヘルツのプロセッサ上での測定の一組[ヤング]、DES EDE3が1024個のバイトブロックを使用して、毎秒1646210バイトと高い行うことが示されました。同じテストベッドはRC4ためcast5CBC毎秒7147760バイト、および毎秒22419840バイトの性能が得られました。ほとんどのTLSセッションはRC4暗号を交渉します。 LIPKEYが厳しくLIPKEYの有用性を妨げるRC4よりも13倍以上遅く（13倍以上CPU集中）で暗号を選択し、TLSが配備されているものと同様の環境を対象としていることを考えます。パフォーマンス上の理由から、RC4はSPKM-3についての好ましい必須のアルゴリズムだろう。 RC4 [シュナイアー]、cast5CBCの合理的なパフォーマンスの組み合わせ、およびそのロイヤリティフリーライセンス条項に知的財産の配慮のために[RFC2144]はcast5CBC DES EDE3、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:
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:
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
md5WithRSAEncryptionザ・md5WithRSAEncryptionの整合性アルゴリズムは必須として、[RFC2025]に記載されています。知的財産の考慮事項[RSA-IP]のため、SPKM-3の実装はすることはできません
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.
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:
md5WithRSAEncryptionの場合と同様の理由sha1WithRSAEncryption、sha1WithRSAEncryptionが推奨アルゴリズムです。 sha1WithRSAEncryptionアルゴリズムが原因MD5ハッシュアルゴリズム[Dobbertin]の弱点に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].
sha1WithRSAEncryptionのアルゴリズムOIDおよび説明のための基準は、[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は、対象の応答に応答するターゲット応答（REP-TI-TOKEN）、そして最後に開始剤が第二のトークン（REP-IT-TOKEN）を開始最初のトークン（REQ-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は、この覚書で前述使用しなければなりません。これは、Integrityフィールドの長さゼロのビット列を生成します。
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はRSAEncryption K-ALGが存在する、SPKM-1は、その公開鍵証明書に目標（TARG-名）にマップすることができなければならないことを要求し、したがって、SPKMは、キーestb-を埋めるRSAEncryptionアルゴリズムを使用することができるのでREQフィールド。 LIPKEYが低いインフラの展開を想定しているため、SPKM-3は、REQ-コンテンツフィールドのTARG-nameフィールドをマップすることができないために準備しなければなりません。これはdhKeyAgreementアルゴリズムをサポートするために、SPKM-3を必要とすることによって解決される矛盾です。 SPKM-3の実装は、証明書にターゲットをマッピングしようとし、そして成功した場合、RSAEncryption K-ALGアルゴリズムを使用することは自由であることに留意されたいです。また、REQ-TOKEN式にNULL-MAC以外のalgIDを使用して自由です。
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.
REQ-コンテンツのキーESTBセットフィールドでのみK-ALGがdhKeyAgreementある場合SPKM-3の実装は、1にターゲットcertifデータ-必要なビットを設定しなければなりません。 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で仕様から導出することができる例外はalgIdとREP-TI-INTEGフィールドです。
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のalgIdがある場合、ターゲットは、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イニシエータとターゲットは、アルゴリズムのセットをネゴシエートそれらが相互に支持、ゼロのQOPが指定されている場合、イニシエータとターゲットは、第一C-ALG（プライバシ）を使用するRFC 2025のセクション5.2で定義された手順を使用して、およびI-ALG（整合性）アルゴリズムが交渉しました。
SPKM breaks the QOP into several fields, as reproduced here from Section 5.2 of RFC 2025:
RFC 2025のセクション5.2から、ここで再現してSPKMは、いくつかのフィールドに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-3は、SPKMファミリー内には、それぞれの機密性と完全性フィールドの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.
「0010」の機密性MAアルゴリズム値をネゴシエート「0001」と「0010」のベースにある2アンSPKMピアは、128ビットキーを使用しなければならない場合、すなわち、128ビットにcast5CBCパラメータでKEYLENGTH値を設定します。
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ためのサポートを追加、以前に述べたように、のでSPKM-1およびSPKM-2の下位互換性を損なわない、SPKMアルゴリズムを交渉します。古いcast5CBCのためのMA値を認識しないSPKM-1またはSPKM-2、ID-DSA-で-SHA1、HMAC-MD5、またはsha1WithRSAEncryptionは、それらを選択しません。
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トークンを生成するためにSPKM-3を起動します。アプリケーションが使用するメカニズムはLIPKEYあるので、LIPKEYはLIPKEY接頭辞SPKM-3のトークンの一部をラップします。トークンの正確な定義は、この覚書に後述します。
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_C_NT_HOSTBASED_SERVICE名のタイプを使用して、一般的に、必ずしも必要ではないが、対象者の名前をインポートするGSS_Import_nameを使用しています。 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 [サンドバーグ]クライアントとしてのオペレーティング・システムに組み込まれたアプリケーションは、情報の入力を求めるプロンプトが表示コマンドを呼び出すために彼に言って、ユーザーの端末にメッセージをブロードキャストすることがあります。
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引数は単にたdesired_name引数に対応するプリンシパルにマッピング参照あろう。それは、ユーザー名とパスワードを取得する際、後続もしGSS_Init_sec_contextの呼び出しは、プリンシパルにclaimant_cred_handleのマッピングを検討します。例えば、前述のポップアップウィンドウがclaimant_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である場合、LIPKEY機構は、次に、前述の要件に従って実施SPKM-3機構にもしGSS_Init_sec_contextを呼び出します。 SPKM-3へのこの呼び出しは、以下の属性を持っている必要があります。
* claimant_cred_handle is NULL
* claimant_cred_handleはNULLです
* mutual_req_flag is FALSE
* mutual_req_flagはFALSEです
* anon_req_flag is TRUE
* anon_req_flagはTRUEです
* input_token is NULL
*入力トークンは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.
ダウンSPKM-3機構に上記の属性は、LIPKEYメカニズムからもし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の呼び出し元がTRUEまたはFALSEにanon_req_flag設定するかどうかに依存します。
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の呼び出し側がTRUEにanon_req_flagを設定した場合、それはoutput_context_handle、のoutput_token、およびメカニズム種別を含め、LIPKEY発信者にSPKM-3もしGSS_Init_sec_contextの呼び出しからのすべての出力を返さなければなりません。返された出力のものはLIPKEYに関係しないので、この方法では、LIPKEYは今、アプリケーションおよび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.
LIPKEYメカニズムは、自身のためにコンテキスト・ハンドルを割り当てる必要があります、そしてレコードがLIPKEYコンテキストでSPKM-3もしGSS_Init_sec_contextルーチンへの呼び出しからoutput_context_handleパラメータに返されたSPKM-3コンテキストハンドルを扱います。 LIPKEYもしGSS_Init_sec_contextルーチンはLIPKEY機構タイプ、LIPKEYコンテキスト・ハンドルoutput_context_handleで戻り、メカニズム種別でます。後でこのメモで定義されるようなた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_CONTINUE_NEEDEDのmajor_statusが表示され、そのLIPKEYの呼び出し側は、ターゲットにたoutput_tokenを送信します。 LIPKEYの呼び出し側は、ターゲットの応答トークンを受信して、二度目のLIPKEYもしGSS_Init_sec_contextルーチンを呼び出します。 LIPKEYは、第2の時間SPKM-3もしGSS_Init_sec_contextを呼び出し、復帰時に、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_sec_contextルーチンの最初の呼び出し時にclaimant_cred_handleを経由して、それに渡されたユーザー名とパスワードを送信する必要があるため、LIPKEYのコンテキストの確立は、まだ完全ではありません。 LIPKEYはclaimant_cred_handleは（ユーザ名とパスワード）を意味するもの暗号化する（TRUEに設定conf_req_flag有する）にGSS_Wrapへの入力として確立SPKM-3コンテキスト・ハンドルを使用し、LIPKEYの呼び出し元へのoutput_tokenとして（conf_stateを提供したことを返しますGSS_S_CONTINUE_NEEDEDのmajor_statusとともにコールからSPKM-3のにGSS_Wrapが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の発信者は、ターゲットへの第二のコンテキスト確立トークンを送信し、ターゲットの場合gss_accept_sec_contextルーチンによって提供されるトークンを待ちます。ターゲットのLIPKEYのgss_accept_sec_contextルーチンはトークン上SPKM-3はgss_unwrapルーチンを呼び出して、ユーザー名とパスワードを検証します。ターゲットは、ユーザー名とパスワードが受け入れられたかどうかを示すブール値にSPKM-3のにGSS_Wrapルーチンを呼び出し、場合gss_accept_sec_contextのためのoutput_token結果にGSS_Wrapからoutput_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の呼び出し側は、ターゲットの応答トークンを受信し、LIPKEYもしGSS_Init_sec_contextルーチンに入力トークンパラメータを経由して、これを渡します。 LIPKEYは、ブール受諾表示を得るためにはgss_unwrapを呼び出し、成功した（ブール値がTRUEだった）とLIPKEYコンテキストの確立を完了、またはGSS_S_FAILUREを示すGSS_S_COMPLETEのいずれかのmajor_statusにこれをマッピングし、そのコンテキストの確立が失敗したかを示します。 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.
一方的な認証が不可能であるためmutual_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.
LIPKEYコンテキストが確立されている間SPKM-3コンテキストが確立されたまま。 LIPKEYコンテキストが破壊される前に、SPKM-3コンテキストの有効期限が切れた場合は、LIPKEYの実装はLIPKEY文脈を期限切れにし、次の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コンテキストとLIPKEYコンテキストの状態の変更に至るパスを必要とします。
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.
ターゲットはSPKM-3は、gss_acquire_credルーチンを経て、SPKM-3ターゲットの資格を取得するためにLIPKEYは、gss_acquire_credルーチンを呼び出します。たdesired_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である場合、LIPKEY機構は、次に、前述の要件に従って実現SPKM-3機構に場合gss_accept_sec_contextを呼び出します。 SPKM-3へのこの呼び出しは、1つの場合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.
すべてがうまくいけば、SPKM-3のgss_accept_sec_contextの呼び出しがGSS_S_COMPLETEで成功し、LIPKEY場合gss_accept_sec_contextの呼び出しは、呼び出し側にたoutput_tokenを返しますが、GSS_S_CONTINUE_NEEDEDのmajor_statusでLIPKEY開始剤はまだユーザー名とパスワードを送信することが予想されるため。
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コールの出力によって包まれ、ユーザー名とパスワードが含まれます受け取ります。ターゲットは、順番にSPKM-3はgss_unwrapルーチンを呼び出すLIPKEYのgss_accept_sec_contextを呼び出します。 LIPKEYのgss_accept_sec_contextルーチンは、そのユーザー名名とパスワードのデータベースとユーザー名とパスワードを比較します。イニシエータのユーザー名とパスワードが有効な場合、GSS_S_COMPLETEが呼び出し元に返されます。そうでなければGSS_S_FAILUREが返されます。いずれの場合においても、たoutput_token - ブール値にSPKM-3にGSS_Wrap呼び出しからoutput_message結果に等しいが、 - 呼び出し側に戻されます。ユーザー名とパスワードが、そうでなければFALSE有効であった場合はブール値が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で定義されたすべての名前の種類が必要なRFC 2078で定義された独立した名前タイプのみメカニズムを使用しています。
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では、thisMechはLIPKEYのためのオブジェクト識別子になります。しかし、限りLIPKEYがSPKM-3メカニズムを確立していないとして、innerContextTokenはInitialContextTokenとSubsequentContextToken両方にSPKM-3もしGSS_Init_sec_context又は場合gss_accept_sec_contextの出力となります。だから、LIPKEY innerContextTokenのいずれかのようになります。
* An InitialContextToken, with thisMech set to the object identifier for SPKM-3, with innerContextToken defined to be an SPKMInnerContextToken, as defined in RFC 2025.
*アンInitialContextToken、RFC 2025で定義されるように、SPKMInnerContextTokenであると定義innerContextTokenとSPKM-3のオブジェクト識別子にthisMechセットです。
* A SubsequentContextToken, with innerContextToken defined to be SPKMInnerContextToken
SPKMInnerContextTokenされるように定義innerContextTokenと* A SubsequentContextToken、
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つのトークンがイニシエータに戻りました。
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イニシエータは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:
ターゲットは、イニシエータからユーザ名とパスワードトークンを検証し、および（またはTRUEに設定してもしなくてもよいconf_req）SPKM-3にGSS_Wrapの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
1が見ることができるように、PerMSGTokenまたはSealedMessageには独立したメカニズムのプレフィックス、および明示的なメカニズムの特定の情報はありません。 LIPKEYはGSS_GetMICに任意の値を追加しませんので、と
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.
SPKM-3 GSS_GetMICとにGSS_Wrapにメッセージを渡す以外にGSS_Wrap、LIPKEYのPerMsgTokenとSealedMessageトークンはSPKM-3のGSS_GetMICとにGSS_Wrapルーチンが生み出すまさにです。
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、SPKM-3をするためにGSS_WrapとGSS_GetMICために通過され、解釈または変更のQOP前述のルーチンに渡される、またはその相補体から受信し、はgss_unwrap、及びGSS_VerifyMICありません。したがって、LIPKEYがSPKM-3などのQOPの同じセットをサポートしています。
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
cast5CBC暗号化アルゴリズムは、トリプルDES、およびRC4のような確立されたアルゴリズムに比べて比較的新しいものです。それにもかかわらず、SPKM-3用MANDATORY C-ALGとしてcast5CBCの選択は賢明です。 cast5CBCアルゴリズムは、256ビットcast6CBC [RFC2612]アルゴリズムが基づいている128ビットアルゴリズムです。 cast6CBCアルゴリズムは、「セキュリティのギャップ」は知らメジャーまたはマイナーを持っていないし、「高度なセキュリティマージン」[AES]を持っている米国国立標準技術研究所（NIST）によって判断しました。 NISTは、いくつかの脆弱性に注意しました
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.
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.、バーカー、E.、ドッドソン、D.、Dworkin、M.、FOTI、J.、Roback、E.（無期限が、遅くとも1999より）。 「高度暗号化規格の開発の第一ラウンドの現状報告。」 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、第2巻、ナンバー2 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]電子フロンティア財団（EFF）、ジョン・ギルモア（編集）（1998）。 「割れデス：暗号研究と盗聴政策＆チップ設計の秘密、」オライリー＆アソシエーツ、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研究所（1993）。 "PKCS＃3：のDiffie-Hellman鍵合意規格、バージョン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.、フォード、W.、ポーク、W.、ソロ、D.、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル" が進行中で働いています。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[RFC1831]スリニバサン、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 1831、1995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832]スリニバサン、R.、 "XDR：外部データ表現標準"、RFC 1832、1995年8月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]リン、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]アイスラー、M.、チウ、A.及びL.リン、 "RPCSEC_GSSプロトコル仕様"、RFC 2203、1997年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]アダムス、C.、 "単純な公開鍵GSS-APIメカニズム（SPKM）"、RFC 2025、1996年10月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]リン、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、ベラー、M。およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]アダムス、C.、 "CAST-128暗号化アルゴリズム"、RFC 2144、1997年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "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.及び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.、フォード、W.、ポーク、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 2459、1999年1月。
[RFC2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, June 1999.
[RFC2612]アダムス、C.及びJ.ギルクリスト、 "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で場所です。これと他の技術について受領したIPR情報を表示するには、このWebページをご確認ください。
[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.
【サンドバーグ]サンドバーグ、R.、ゴールドバーグ、D.、クレイマン、S.、ウォルシュ、D.、リヨン、B.（1985）。 「日ネットワークファイルシステムの設計と実装、」1985年夏のUSENIX技術会議の議事。
[Schneier] Schneier, B. (1996). "Applied Cryptography," John Wiley & Sons, Inc., ISBN 0-471-11709-9.
[シュナイアー]シュナイアー、B.（1996）。 "応用暗号、" John Wiley＆Sons社、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.
*ジャック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.
*この覚書は、ジョン・リンによって作成された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.
*この覚書は、ASN.1定義とカーライルアダムスによって書かれたRFC 2025でSPKMの定義から、他のテキストを含んでいます。
Author's Address
著者のアドレス
Address comments related to this memorandum to:
この覚書に関連するコメントを住所：
ietf-cat-wg@lists.Stanford.EDU
いえｔｆーかｔーｗｇ＠ぃｓｔｓ。Ｓたんふぉｒｄ。えづ
Mike Eisler Zambeel 5565 Wilson Road Colorado Springs, CO 80919
マイク・アイスラーZambeel 5565ウィルソン道路コロラドスプリングス、CO 80919
Phone: 1-719-599-9026 EMail: mike@eisler.com
電話：1-719-599-9026 Eメール：mike@eisler.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。