RFC2847 日本語訳
2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM. M.Eisler. June 2000. (Format: TXT=50045 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Eisler Request for Comments: 2847 Zambeel Category: Standards Track June 2000
コメントを求めるワーキンググループM.アイスラー要求をネットワークでつないでください: 2847年のZambeelカテゴリ: 標準化過程2000年6月
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
LIPKEY--SPKMを使用する低いインフラストラクチャ公開鍵メカニズム
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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]を使用できる方法を説明します、パスワード、および公開鍵証明書があるサーバでクライアントを認証して。 そういうものとして、それはTransport Layer Security(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.
方法は、既存のSimple Public Key Mechanism(SPKM)[RFC2025]に投機して、別々のGSS-APIメカニズム(LIPKEY)がSPKMの上で層にされたので、指定されます。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 LIPKEYのSPKM. . . . . . . . . . . . . . . . 4 2.1の要件。 メカニズムタイプ. . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 タイプ. . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3を命名してください。 アルゴリズム. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1。 義務的なアルゴリズム. . . . . . . . . . . . . . . . . . . 5 2.3.2。 お勧めの保全アルゴリズム(I-ALG).72.4。 文脈設立象徴. . . . . . . . . . . . . . . . 8 2.4.1。 REQ-TOKEN Content Requirements. . . . . . . . . . . . . . 8 2.4.1.1algIdとreq-保全.82.4、.1 .2。 .1をReqに.82.4に満足させる、.2 .1。 オプション、.92.4 .1 .2 .2。 Conf-Algs、.92.4 .1 .2 .3。 Intg-Algs. . . . . . . . . . . . . . . . . . . . . . 9
Eisler Standards Track [Page 1] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[1ページ]。
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
2.4.2. REP-TI-TOKEN Content Requirements. . . . . . . . . . . . 9 2.4.2.1algId. . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.2.2レップ-ti-integ.92.5。 保護(QOP). . . . . . . . . . . . . . . .10 3の品質。 LIPKEYはどうSPKM. . . . . . . . . . . . . . . . . . . . 11 3.1を使用するか。 象徴. . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2。 創始者. . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1。 GSS_輸入_名. . . . . . . . . . . . . . . . . . . . 11 3.2の.2。 GSS_は_信用. . . . . . . . . . . . . . . . . . . . 11 3.2.3を取得します。 GSS_イニット_秒_文脈. . . . . . . . . . . . . . . . . . 12 3.2.3の.1。 LIPKEY Caller Specified、_やがて、req_はTRUE. . . . 12 3.2.3として.2に弛みます。 LIPKEY Caller Specified、_やがて、req_はFALSE. . . . 13 3.2として.4に弛みます。 他の操作. . . . . . . . . . . . . . . . . . . . 14 3.3。 目標. . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1。 GSS_輸入_名. . . . . . . . . . . . . . . . . . . . 14 3.3の.2。 GSS_は_信用. . . . . . . . . . . . . . . . . . . . 14 3.3.3を取得します。 GSS_は_秒_文脈. . . . . . . . . . . . . . . . . 15 4を受け入れます。 LIPKEY記述. . . . . . . . . . . . . . . . . . . . . 15 4.1。 メカニズムタイプ. . . . . . . . . . . . . . . . . . . . . . 15 4.2。 タイプ. . . . . . . . . . . . . . . . . . . . . . . . 15 4.3を命名してください。 象徴は.1に.164.3をフォーマットします。 文脈象徴. . . . . . . . . . . . . . . . . . . . . 16 4.3.1.1。 SPKM-3文脈設立. 16 4.3.1.2の前の文脈象徴。 ポスト-SPKM-3文脈設立象徴. . . . . . . 16 4.3.1.2.1。 LIPKEY創始者. . . . . . . . . . . . . . . 17 4.3.1.2、.2 LIPKEY目標. . . . . . . . . . . . . . . . . 17 4.3.2から。 GSS_GetMICとGSS_からの象徴は.174.4を包装します。 保護. . . . . . . . . . . . . . . . . . 18 5の品質。 セキュリティ問題. . . . . . . . . . . . . . . . . . 18 5.1。 パスワード管理. . . . . . . . . . . . . . . . . . . 18 5.2。 証明当局. . . . . . . . . . . . . . . . 18 5.3。 HMAC-MD5とMD5弱点. . . . . . . . . . . . . . . 18 5.4。 cast5CBC. . . . . . . . . . . . . . . . . . . 18参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 19承認. . . . . . . . . . . . . . . . . . . . . . . . 21作者のアドレスの.21の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 22のセキュリティ
1. Introduction
1. 序論
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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
このメモはLow Infrastructure Public Key Mechanism(LIPKEY)と呼ばれるGSS-APIの下で新しいセキュリティー対策について説明します。 GSS-APIはアプリケーション・プロトコルが認証、保全、およびプライバシーを実行する方法を提供します。 TLSは別の方法です。 TLSをゆったり過ごしてください。
Eisler Standards Track [Page 2] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[2ページ]。
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.
多くの道における取り入れるGSS APIより簡単なアプリケーションであり、状況がGSS-APIが、より適当であるかもしれないところにあります。 確かに、これはコネクションレスプロトコルをひくアプリケーション・プロトコルがあるそうです。 また、[RFC2203](それら自身のセキュリティー体系を持っているので容易にプロトコルと合わない)が上側の層のアプリケーション・プロトコルを要約する層として実行されるTLSが好きであるのは、ONC RPC[RFC1831]などのアプリケーション・プロトコルがあるケースです。 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),
* それが信じられた認証局(カリフォルニア)によってサインされたことを確かめます。
* 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実現に加えて、必要なセキュリティインフラストラクチャはサーバに関する公開鍵証明書とパスワードデータベース、およびクライアントの上の信じられたCAsと彼らの公開鍵のリストを含んでいます。 したがって、ネットの追加インフラストラクチャは、httpサーバが動くほとんどのオペレーティングシステムが既に固有のパスワードデータベースを持って、サーバ証明書とカリフォルニアリストです。 したがって、この典型的なTLS展開シナリオを特定する「低いインフラストラクチャ機密保護モデル」という用語。
Eisler Standards Track [Page 3] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[3ページ]。
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)。
2. LIPKEY's Requirements of SPKM
2. LIPKEYのSPKMの要件
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と同じメカニズムタイプObject Identifier(OID)を使用するのを含んでいる)、変化のセットの中でこれらの意味変化を実行するには、互換性が危険にある肝心のRFC2025の解釈を伸ばしてください。 SPKM3と呼ばれる新しいメカニズムタイプは保証されます。 LIPKEYは、SPKM実現がSPKM-3を支持するのを必要とします。 このセクションの残りで説明されるのを除いて、SPKM-3はSPKM-1に同等です。
2.1. Mechanism Type
2.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)}
spkm-3 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)spkm(1)spkm-3(3)
2.2. Name Type
2.2. 名前タイプ
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.
RFC2025はSPKMのどんな必要な名前タイプも定義しません。 LIPKEYは、SPKM-3実現がRFC2078のタイプというすべてのメカニズムの独立している名をサポートするのを必要とします。
Eisler Standards Track [Page 4] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[4ページ]。
2.3. Algorithms
2.3. アルゴリズム
2.3.1. MANDATORY Algorithms
2.3.1. 義務的なアルゴリズム
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.
RFC2025は保全、秘密性、主要な設立、およびサブキー派生のための様々なアルゴリズムを定義します。 md5WithRSAEncryptionを除いて、RFC2025に記載されたSubkey Derivation(O-ALG)アルゴリズムのためのREQUIRED Key特権階級(K-ALG)、Integrity(I-ALG)、およびOne-道のFunctionsはずっとREQUIREDです。
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 Becauseには、それ自体のための証明書がないかもしれません、または、目標には、目標に送られる創始者のREQ-TOKENでIntegrity値について計算するのは、可能ではありません。 それで、私たちは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)}
ヌルMac物の識別子:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)保全(3)ヌル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:
sha1 Thisとイドdsaは.2セクション7.2[RFC2459]で定義されるように署名アルゴリズムです。 RFC2459に述べられるように、この署名アルゴリズムを特定するのに使用されるASN.1OIDは以下の通りです。
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 3
}
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(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]があることに注意して、RFC2459を時代遅れにしてください。 しかしながら、その処理中の作業はsha1とイドdsaの定義を変えません。
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
証明書を持っていないSPKM-3創始者のHMAC-MD5A結果は文脈がいったん確立されるとmd5WithRSAEncryptionのようなデジタル署名アルゴリズム、sha1とイドdsa、またはsha1WithRSAEncryptionを使用できないということです。 代わりに、メッセージ確認コード(MAC)アルゴリズムはそうです。
Eisler Standards Track [Page 5] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[5ページ]。
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:
必要。 DES-MACは[RFC2025]で推薦されるように指定されます。 56ビットのDESのセキュリティが不十分に[EFF]なるように示されたので、SPKM-3は、より強いMACを必要とします。 したがって、SPKM-3 MUSTはこの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
}
HMAC-MD5物の識別子:、:= iso(1) org(3) dod(6)インターネット(1)セキュリティ(5)メカニズム(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].
SHA-1がMD5[若い]の速度のおよそ半分ので、HMAC-SHA1アルゴリズムは義務的なSPKM-3 I-ALG MACではありません。 MD5が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:
RFC2025はMANDATORY秘密性アルゴリズムを持っていなくて、代わりに56ビットのRECOMMENDED a DESアルゴリズムを持っています。 LIPKEY創始者が、パスワードを目標に送る必要があって、56ビットのDESが不十分[EFF]としてデモをしたので、LIPKEYは、より強い暗号化を必要とします。 したがって、SPKM-3 MUSTはこのアルゴリズムを支持します:
cast5CBC OBJECT IDENTIFIER ::= {
iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
algorithms(66) 10
}
cast5CBC物の識別子:、:= iso(1) memberBody(2) usa(840) nt(113533) nsn(7)アルゴリズム(66)10
Parameters ::= SEQUENCE {
iv OCTET STRING DEFAULT 0, -- Initialization vector
keyLength INTEGER -- Key length, in bits
}
パラメタ:、:= 系列iv OCTET STRING DEFAULT0--初期設定ベクトルkeyLength INTEGER--ビットのキー長
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]です。 Parametersの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
それがcast5CBCよりはるかに遅いので、三重のDES(DES EDE3)アルゴリズムは義務的なSPKM-3C ALGではありません。 DES EDE3が1秒あたり164万6210バイトと同じくらい高く働いたのを示して、1024年のバイトのブロックを使用して、SSLeayコードを使用するPentium Pro200メガヘルツプロセッサの上の1セットの測定値[若い]。 同じくらい
Eisler Standards Track [Page 6] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[6ページ]。
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のための1秒あたり714万7760バイト、およびRC4のための1秒あたり2241万9840バイトの性能をもたらしました。 ほとんどのTLSセッションがRC4暗号を交渉します。 LIPKEYがTLSが配備されるそんなにところと同様の環境で狙うなら、RC4よりさらに遅くて(13倍さらに多くのCPUの上に徹底的)の13回以上の時勢である暗号を選択すると、LIPKEYの有用性は厳しく妨害するでしょう。 性能理由で、RC4は都合のよいSPKM-3に、義務的なアルゴリズムでしょう。 RC4[シュナイアー]がある知的所有権問題、cast5CBCの妥当な性能の組み合わせ、および[RFC2144]がDES EDE3、RC4、およびcast5CBCの中で特選している最適の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:
RFC2025はdhKeyAgreement[PKCS-3]について明らかに任意のアルゴリズムに記載します。 後で説明されるように、低いインフラストラクチャセキュリティー対策に、RSAEncryptionの主要な設立アルゴリズムはこのメモによって定義されるように無駄です。 したがって、SPKM-3では、dhKeyAgreementはREQUIREDの主要な設立アルゴリズムです:
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
dhKeyAgreement物の識別子:、:= iso(1)は(2) 米国(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:
RFC2025は義務的なアルゴリズムにMD5について記載します。 細切れ肉料理[Dobbertin]として使用されるとMD5が弱点を持っているのがわかったので、イドsha1はSPKM-3のMANDATORY O-ALGです:
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26
}
イド-sha1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(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].
イド-sha1のアルゴリズムOIDの参照は[RFC2437]です。 イド-sha1のSHA-1アルゴリズム対応の参照は[FIPS]です。
2.3.2. RECOMMENDED Integrity Algorithms (I-ALG)
2.3.2. お勧めの保全アルゴリズム(I-ALG)
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]に記載されています。 SPKM-3実現は知的所有権問題[RSA-IP]のためにであるはずがありません
Eisler Standards Track [Page 7] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[7ページ]。
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は証明書がRSA公開鍵を使用する増殖を考えて、強くそうです。RECOMMENDED。 さもなければ、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:
md5WithRSAEncryptionに、それと同様のsha1WithRSAEncryption For理由であり、sha1WithRSAEncryptionはRECOMMENDEDアルゴリズムです。 MD5細切れ肉料理アルゴリズム[Dobbertin]でsha1WithRSAEncryptionアルゴリズムは弱点によるmd5WithRSAEncryptionに加えて記載されています。 sha1WithRSAEncryptionのためのOIDは以下の通りです。
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5
}
sha1WithRSAEncryption物の識別子:、:= iso(1)は(2) 米国(840)rsadsi(113549) pkcs(1) pkcs-1(1)5をメンバーと同じくらい具体化させます。
The reference for the algorithm OID and description of
sha1WithRSAEncryption is [RFC2437].
アルゴリズムOIDの参照とsha1WithRSAEncryptionの記述は[RFC2437]です。
2.4. Context Establishment Tokens
2.4. 文脈設立象徴
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.
RFC2025は、目標の回答に答えるために創始者の最初の象徴(REQ-TOKEN)、目標回答(REP-TI-TOKEN)、および最終的に創始者2番目の象徴(REP IT TOKEN)で文脈をセットアップします。 LIPKEYが一方的な認証があるSPKM-3を使用するので、REP IT TOKENは使用されていません。 LIPKEYには、REQ-TOKENとREP-TI-TOKENのコンテンツに関する、ある要件がありますが、SPKM-3象徴の構文はRFC2025のSPKM-1象徴と異なっていません。
2.4.1. REQ-TOKEN Content Requirements
2.4.1. REQ-象徴の満足している要件
2.4.1.1. algId and req-integrity
2.4.1.1. algIdとreq-保全
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分野でゼロ・レングスビット列を作成するでしょう。
2.4.1.2. Req-contents
2.4.1.2. Req-コンテンツ
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
RFC2025が、RSAEncryption K-ALGが存在しているのを必要とするので、SPKM-1は目標(targ-名前)を公開鍵証明書に写像できなければなりません、そして、その結果、SPKMは主要なestb-req分野に記入するのにRSAEncryptionアルゴリズムを使用できます。 LIPKEYが、低いインフラストラクチャ展開、SPKM-3 MUSTがReq-コンテンツ分野のtarg-名前欄を写像できないように準備されると仮定するので。 これはサポートへのSPKM-3を必要とすることによって決議されている矛盾です。
Eisler Standards Track [Page 8] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[8ページ]。
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.
dhKeyAgreementアルゴリズム。 SPKM-3実現が目標を証明書に写像しようとして、成功するなら、自由にRSAEncryption K-ALGアルゴリズムを使用できることに注意してください。 また、それは自由にREQ-TOKENタイプのNULL-MAC以外のalgIDを使用できます。
2.4.1.2.1. Options
2.4.1.2.1. オプション
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-コンテンツの主要なestbセット分野における唯一のK-ALGがdhKeyAgreementであるなら目標certifデータが必要なビットを1に設定しなければなりません。 SPKM-3実現が目標名を証明書に決議できないなら、通常、これは起こるでしょう。
2.4.1.2.2. Conf-Algs
2.4.1.2.2. Conf-Algs
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を記載しなければなりません。
2.4.1.2.3. Intg-Algs
2.4.1.2.3. Intg-Algs
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 MUSTより弱いアルゴリズムを支持するなら目標を奨励するさらに弱いアルゴリズムの前に記載されて、より強いアルゴリズムを交渉してください。
2.4.2. REP-TI-TOKEN Content Requirements
2.4.2. レップTI象徴の満足している要件
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に関する以前に説明された要件で、RFC2025の仕様からSPKM-3のREP-TI-TOKENのコンテンツをだいたい得ることができます。 例外はalgIdとレップ-ti- integ分野です。
2.4.2.1. algId
2.4.2.1. 寒けがします。
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を使用してはいけません。 それはsha1とイドdsa、md5WithRSAEncryption、またはsha1WithRSAEncryptionのような署名アルゴリズムを使用しなければなりません。
2.4.2.2. rep-ti-integ
2.4.2.2. レップ-ti-integ
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-コンテンツとレップtiコンテンツの連結のときにレップ-ti-integを計算しなければなりません。
Eisler Standards Track [Page 9] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[9ページ]。
2.5. Quality of Protection (QOP)
2.5. 保護の品質(QOP)
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創始者と目標はそれらが互いに支持するアルゴリズムのセットを交渉します、RFC2025のセクション5.2で定義された手順を用いて。 ゼロのQOPが指定されると、創始者と目標は交渉された最初のC-ALG(プライバシー)、およびI-ALG(保全)アルゴリズムを使用するでしょう。
SPKM breaks the QOP into several fields, as reproduced here from Section 5.2 of RFC 2025:
SPKMはここでRFC2025のセクション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) |
-------------------------------|-------------------------------
秘密性保全31(MSB)16 15(LSB)0-------------------------------|------------------------------- | t(5)| U(3)| アイオワ(4)| MA(4)| t(5)| U(3)| アイオワ(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を導入するので、それぞれのConfidentialityとIntegrity分野のMA部分体にアルゴリズムを加えるのは適切です。
The complete set of Confidentiality MA algorithms is thus:
その結果、完全なセットのConfidentiality MAアルゴリズムは以下の通りです。
0001 (1) = DES-CBC
0010 (2) = cast5CBC
0001(1)=DES-CBC0010(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.
どこ、「1インチと「10インチがベース2であるか」。 「10インチは128ビットのキーを使用しなければなりません、すなわち、keyLengthがcast5CBCパラメタで128ビットに評価するセット」の秘密性MAアルゴリズム価値を交渉するSPKM同輩。
The complete set of Integrity MA algorithms is thus:
その結果、完全なセットのIntegrity MAアルゴリズムは以下の通りです。
0001 (1) = md5WithRSAEncryption
0010 (2) = DES-MAC
0011 (3) = id-dsa-with-sha1
0100 (4) = HMAC-MD5
0101 (5) = sha1WithRSAEncryption
HMAC-MD5 0101sha1とイドdsa0100DES-MAC0011md5WithRSAEncryption0010 0001(1)=(2)=(3)=(4)=(5)はsha1WithRSAEncryptionと等しいです。
Where "0001" through "0101" are in base 2.
「「0101」を通した1インチがベース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が以前に注意されるようにアルゴリズムを交渉するので、SPKM-1とSPKM-2への上の方法でcast5CBC、sha1とイドdsa、HMAC-MD5、およびsha1WithRSAEncryptionのサポートを加えるのはSPKM-1とSPKM-2の後方の互換性を損ないません。cast5CBC、sha1とイドdsa、HMAC-MD5、またはsha1WithRSAEncryptionとしてMA値を認識しないより古いSPKM-1かSPKM-2がそれらを選択しないでしょう。
Eisler Standards Track [Page 10] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[10ページ]。
3. How LIPKEY Uses SPKM
3. LIPKEYはどうSPKMを使用するか。
3.1. Tokens
3.1. 象徴
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象徴を包装するでしょう。 象徴の正確な定義は後でこのメモで説明されます。
3.2. Initiator
3.2. 創始者
3.2.1. GSS_Import_name
3.2.1. GSS_輸入_名
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_名を使用します。 LIPKEY目標がSPKM-3目標であるので、結局、GSS_Import_名の出力はSPKM-3メカニズムタイプに適用されるでしょう。
3.2.2. GSS_Acquire_cred
3.2.2. GSS_は_信用を取得します。
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_信用と呼びます。 後天的な信任状は、LIPKEY信任状と、ユーザ名とパスワードです。 ユーザ名とパスワードがどう後天的であるかは、操作環境に依存しています。 () グラフィカルユーザーインターフェースが走って、アプリケーションのユーザが呼び出しましたが、GSS_Acquire_信用を呼び出すアプリケーションはそれが情報のためにうながす打ち上げウィンドウの外観の引き金となるかもしれません。 オペレーティングシステムに埋め込まれた固有のファイルシステムとして実行された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_秒_文脈が呼ばれるまで信任状が使用されないので、LIPKEY実現は、信任状を保護する必要があるでしょう。 これが問題であるなら、GSS_イニット_秒_関係がユーザ名とパスワードを目標に送る準備ができるまで、実現は代わりにユーザ名とパスワードの実際の習得を延期するかもしれません。 その場合には、GSS_Acquire_信用の出力_信用_ハンドル議論は単にそれが議論という必要な_名に対応する校長に写像した参照でしょう。 ユーザ名とパスワードを習得するとき、その後のGSS_Init_秒_文脈呼び出しは主張者_信用_ハンドルに関するマッピングを校長と考えるでしょう。 例えば、前述の打ち上げウィンドウは校長への地図が主張者_信用_ハンドルで言及したデフォルト値で部分という対話のユーザ名に記入するかもしれません。
Eisler Standards Track [Page 11] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[11ページ]。
3.2.3. GSS_Init_sec_context
3.2.3. GSS_イニット_秒_文脈
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_秒_文脈を呼び出すとき、文脈ハンドルがNULLであるなら、LIPKEYメカニズムは順番に以前に説明された要件に従って実行されたSPKM-3メカニズムのGSS_Init_秒_文脈を呼び出すでしょう。 SPKM-3 MUSTへのこの呼び出しには、以下の属性があります:
* claimant_cred_handle is NULL
* 主張者_信用_ハンドルはNULLです。
* mutual_req_flag is FALSE
* 互いの_req_旗はFALSEです。
* anon_req_flag is TRUE
* _やがて、req_旗はTRUEです。
* input_token is NULL
* 入力_象徴はNULLです。
* mech_type is the OID of the SPKM-3 mechanism
* mech_タイプは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.
上の属性がGSS_Init_秒_文脈呼び出しでLIPKEYメカニズムからSPKM-3メカニズムまで達しているのを覚えておいてください。 LIPKEYのGSS_Init_秒_文脈ルーチンを呼び出すアプリケーションに関して課されるどんな特別な制限もありません。 LIPKEY GSS_Init_秒_文脈議論から他のすべての議論を得ます。
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_秒_文脈への呼び出しはSPKM-3文脈ハンドルを作成するでしょう。 LIPKEY GSS_Init_秒_文脈呼び出しの記述の残りはLIPKEY GSS_Init_秒_文脈の訪問者がやがて_req_旗をTRUEかFALSEに設定するかどうかによります。
3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE
3.2.3.1. LIPKEY Caller Specified、_やがて、req_はTRUEとして弛みます。
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_秒_文脈の訪問者がやがて_req_旗をTRUEに設定するなら、すべての出力をSPKM-3 GSS_Init_秒_文脈呼び出しからLIPKEY訪問者に返さなければなりません、出力_文脈_ハンドル、出力_象徴、およびmech_タイプを含んでいて。 このように、現在LIPKEYはアプリケーションとSPKM-3の間でGSS-API処理が「辺ぴになります」、返された出力における何もLIPKEYに関連しないので。 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を使用すると主張するより特徴を支持するのは簡単です、。
Eisler Standards Track [Page 12] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[12ページ]。
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.
すべてがうまく行くなら、SPKM-3を通して必要である_GSS_S CONTINUE_の主要な_状態がLIPKEYの訪問者に返されるので、LIPKEYの訪問者は出力_象徴を目標に送るでしょう。 LIPKEYの訪問者は、次に、目標から応答象徴を受け取って、直接SPKM-3 GSS_Init_秒_文脈を呼び出します。 リターンのときに、主要な_状態はGSS_S_COMPLETEであるべきです。
3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE
3.2.3.2. LIPKEY Caller Specified、_やがて、req_はFALSEとして弛みます。
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メカニズムは、それ自体のために文脈ハンドルを割り当てて、出力_文脈_ハンドルパラメタで呼び出しからSPKM-3 GSS_Init_秒_文脈ルーチンまで返されたSPKM-3文脈ハンドルをLIPKEY文脈ハンドルに記録する必要があるでしょう。 LIPKEY GSS_Init_秒_文脈ルーチンは出力_文脈_ハンドルでLIPKEY文脈ハンドル、および_タイプ、mechのLIPKEYメカニズムタイプを返すでしょう。 後でこのメモで定義される「SPKM-3文脈設立の前の文脈象徴」の権利を与えられた小区分には出力_象徴があります。 他のすべての返された出力がSPKM-3 GSS_Init_秒_文脈ルーチンがLIPKEYに返したものになるでしょう。 すべてがうまく行ったなら、SPKM-3メカニズムはCONTINUE_が必要としたGSS_S_の主要な_状態を返してしまうでしょう。
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_秒_文脈ルーチンの訪問者がCONTINUE_が必要としたGSS_S_の主要な_状態を見るので、LIPKEYの訪問者は出力_象徴を目標に送るでしょう。 LIPKEYの訪問者は、次に、目標の応答象徴を受け取って、もう一度、LIPKEY GSS_Init_秒_文脈ルーチンを呼び出します。 次に、LIPKEYはもう一度SPKM-3 GSS_Init_秒_文脈を呼び出します、そして、リターンのときに、主要な_状態は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の文脈設立はまだ完全ではありません、創始者がLIPKEY GSS_Init_秒_文脈ルーチンへの準備ラッパでの主張者_信用_ハンドルを通してそれに通過されたユーザ名とパスワードを目標に送らなければならないので。 LIPKEYは主張者_信用_ハンドルが言及すること(ユーザ名とパスワード)をコード化するのに入力としてGSS_Wrap(TRUEに設定されたconf_req_旗がある)に確立したSPKM-3文脈ハンドルを使用して、出力_象徴としてLIPKEYの訪問者にそれを返します(呼び出しからSPKM-3のGSS_Wrapまでのconf_州の出力を提供しているのは、TRUEです)、CONTINUE_が必要としたGSS_S_の主要な_状態と共に。
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
LIPKEYの訪問者は、2番目の文脈設立象徴を目標に送って、目標のGSS_Accept_秒_文脈ルーチンで提供された象徴を待ちます。 目標のLIPKEY GSS_Accept_秒_文脈ルーチンは、象徴の上にSPKM-3 GSS_Unwrapルーチンを呼び出して、ユーザ名とパスワードを有効にします。 そして、目標は論理演算子表示のときにSPKM-3のGSS_Wrapルーチンを呼び出します。
Eisler Standards Track [Page 13] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[13ページ]。
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.
ユーザ名とパスワードは、認められて、GSS_Accept_秒_文脈のための出力_象徴結果としてGSS_Wrapから出力_メッセージ結果を返すのであるかどうか
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_秒_文脈ルーチンへの入力_象徴パラメタでこれを通過します。 LIPKEYは次に、論理演算子承認指示を得るためにGSS_Unwrapを呼び出して、GSS_うまくいくのであっ(論理演算子はTRUEであった)て完成したLIPKEY文脈設立を示すS_COMPLETE、または_GSS_S FAILUREの主要な_状態にこれを写像します、文脈設立が行き詰まったのを示して。 CONTINUE_が必要としたGSS_S_は返されないでしょう。
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_旗のパラメタが無視されることに注意してください。 創始者は、ユーザ名とパスワードを伝えるために安全なチャンネルを創造するために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実現は、次のGSS-API操作のときにLIPKEY文脈を吐き出して、適切な誤りを返すべきです。
3.2.4. Other operations
3.2.4. 他の操作
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_秒_文脈や、GSS_Export_秒_文脈や、GSS_Import_秒_文脈や、GSS_Inquire_文脈などの文脈状態について影響するか、または問い合わせる操作がLIPKEY文脈のSPKM-3文脈と州の変更に終えたパスを必要とするでしょう。
3.3. Target
3.3. 目標
3.3.1. GSS_Import_name
3.3.1. GSS_輸入_名
As with the initiator, the imported name will be that of the target.
創始者の場合、輸入された名前は目標のものになるでしょう。
3.3.2. GSS_Acquire_cred
3.3.2. GSS_は_信用を取得します。
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目標のためにSPKM-3 GSS_Acquire_信用ルーチンで信任状を得るためにLIPKEY GSS_Acquire_信用ルーチンを呼びます。 必要な_名はGSS_Import_名からの出力_名前です。
Eisler Standards Track [Page 14] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[14ページ]。
3.3.3. GSS_Accept_sec_context
3.3.3. GSS_は_秒_文脈を受け入れます。
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_秒_文脈を呼び出すとき、文脈ハンドルがNULLであるなら、LIPKEYメカニズムは順番に以前に説明された要件実行されたSPKM-3メカニズムのGSS_Accept_秒_文脈を呼び出すでしょう。 SPKM-3へのこの呼び出しはものが層にされた呼び出しのためにGSS_Accept_秒_文脈に予想することと異なっていません。
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_秒_文脈呼び出しが_GSS_S COMPLETEと共に成功して、LIPKEY創始者がユーザ名とパスワードを送るとまだ予想されているので、LIPKEY GSS_Accept_秒_文脈呼び出しは、出力_象徴を訪問者に返しますが、_GSS_S CONTINUE_の主要な_状態が必要である状態で返します。
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_秒_文脈を呼び出します。(順番に、それは、SPKM-3 GSS_Unwrapルーチンを呼び出します)。 そして、LIPKEY GSS_Accept_秒_文脈ルーチンはそのユーザ名前名とパスワードデータベースとユーザ名とパスワードを比べます。 創始者のユーザ名とパスワードが妥当であるなら、GSS_S_COMPLETEを訪問者に返します。 さもなければ、GSS_S_FAILUREを返します。 どちらの場合ではも、出力_象徴(ブール値でSPKM-3 GSS_Wrap呼び出しからの出力_メッセージ結果と等しい)を訪問者に返します。 FALSE、ユーザ名とパスワードが妥当であったなら、ブール値はTRUEに設定されます。そうでなければ。 目標は訪問者からそれ以上の文脈設立象徴を全く予想しません。
4. LIPKEY Description
4. LIPKEY記述
4.1. Mechanism Type
4.1. メカニズムタイプ
lipkey OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)lipkey(9)}
lipkey OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)lipkey(9)
4.2. Name Types
4.2. 名前タイプ
LIPKEY uses only the mechanism independent name types defined in RFC 2078. All the name types defined in RFC 2078 are REQUIRED.
LIPKEYはタイプというRFC2078で定義されたメカニズムの独立している名だけを使用します。 タイプというRFC2078で定義されたすべての名前がREQUIREDです。
Eisler Standards Track [Page 15] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[15ページ]。
4.3. Token Formats
4.3. 象徴形式
4.3.1. Context Tokens
4.3.1. 文脈象徴
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
}
InitialContextToken:、:= -- 中で示されたオプション指示(代表団など)--メカニズム特有の象徴[APPLICATION0]IMPLICIT SEQUENCEthisMech MechType、innerContextToken、どんなDEFINED BY thisMechも--コンテンツメカニズム詳細--ASN.1構造は必要ではありません。
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
SubsequentContextToken:、:= innerContextToken、いずれ--前任者InitialContextTokenに基づく解釈--ASN.1構造は必要ではありません。
The contents of the innerContextToken depend on whether the SPKM-3 context is established or not.
innerContextTokenの内容はSPKM-3文脈が確立されるかどうかによります。
4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment
4.3.1.1. 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のためにObject識別子になるでしょう。 しかしながら、LIPKEYがSPKM-3メカニズムを確立していない限り、InitialContextTokenとSubsequentContextTokenの両方のためのinnerContextTokenはSPKM-3 GSS_Init_秒_文脈かGSS_Accept_秒_文脈の出力になるでしょう。 それで、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、thisMechと共に、innerContextTokenがSPKMInnerContextTokenになるように定義されている状態で、2025はRFCで定義されるようにSPKM-3のための物の識別子にセットしていました。
* A SubsequentContextToken, with innerContextToken defined to be
SPKMInnerContextToken
* innerContextTokenがSPKMInnerContextTokenになるように定義されているSubsequentContextToken
4.3.1.2. Post-SPKM-3 Context Establishment Tokens
4.3.1.2. ポスト-SPKM-3文脈設立象徴
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つの象徴が創始者に戻りました。
Eisler Standards Track [Page 16] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[16ページ]。
4.3.1.2.1. From LIPKEY Initiator
4.3.1.2.1. LIPKEY創始者から
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の入力_メッセージ議論は以下で定義されたUserName-パスワードタイプの例を示します:
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
}
ユーザ名パスワード:、:= 系列ユーザ名OCTET STRING--各八重奏はaの八重奏です--UTF-8[RFC2279]はパスワードOCTET STRINGを結びます--各八重奏はaの八重奏です--、UTF-8[RFC2279]は結びます。
4.3.1.2.2. From LIPKEY Target
4.3.1.2.2. LIPKEY目標から
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に用意ができるかもしれない)呼び出しの出力_メッセージ結果である応答象徴を発生させます。 GSS_Wrapの入力_メッセージ議論は以下で定義されたValid-UNPタイプの例を示します:
Valid-UNP ::= BOOLEAN
-- If TRUE, user name/password pair was valid.
有効なUNP:、:= ブール、--TRUEであるなら、ユーザ名前/パスワード組は有効でした。
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap
4.3.2. GetMICとGSS_が包装するGSS_からの象徴
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
RFC2078はGSS_GetMICとGSS_Wrapによって放たれた象徴を以下と定義します。 PerMsgToken:、:= -- GSS_GetMICによって放たれていて、GSS_VerifyMICによって処理されるように、必要です、--ASN.1構造は少しもinnerMsgTokenを必要としませんでした。
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
SealedMessage:、:= -- 放たれている、GSS_Unwrapによって_Wrapであって処理されたGSS--内部の、そして、メカニズムで定義されたインディケータを含んでいます--、コード化される、--ASN.1構造は少しもsealedUserDataが必要でなかった
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
人が見ることができるように、PerMSGTokenかSealedMessageにもかかわらず、どんな明白なメカニズム特殊情報にもどんなメカニズムの独立している接頭語もありません。 そして以来LIPKEYがGSS_GetMICに少しの価値も高めない。
Eisler Standards Track [Page 17] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[17ページ]。
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、LIPKEYのPerMsgToken、およびSealedMessage象徴にメッセージを通過するのを除いたGSS_WrapはまさにSPKM-3のGSS_GetMICとGSS_Wrapルーチンが生産することです。
4.4. Quality of Protection
4.4. 保護の品質
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.
GSS_WrapとGSS_GetMICにおいてSPKM-3に終えたパスであり、LIPKEYは前述のルーチンに移られたか、または1の補数から受け取られたQOPs、GSS_Unwrap、およびGSS_VerifyMICを解釈もしませんし、変更もしません。 したがって、LIPKEYはSPKM-3としてのQOPsの同じセットを支えます。
5. Security Considerations
5. セキュリティ問題
5.1. Password Management
5.1. パスワード管理
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によってコード化されたクリアテキストパスワードを送るので、このアプローチにおけるリスクがそれでそれをした後に目標がどうパスワードを管理するかであります。 アプローチは安全であるべきです、目標がパスワードを含んだメモリ(ディスクなどのような第一の、そして、二次の)バッファをきれいにして、それ直後パスワードのどれか細切れ肉料理がユーザのパスワードを有効にしたなら。
5.2. Certification Authorities
5.2. 証明当局
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.
創始者には、信じられたCertification Authoritiesのリストが、SPKM-3目標の文脈回答象徴の上でチェックサム(レップ-ti-integ)について確かめるためになければなりません。 未知の、そして/または、信頼されていない認証局によってサインされた証明書に遭遇するなら、創始者は静かに証明書を受け入れてはいけません。 証明書を受け入れたいなら、それはGSS-APIを使用しているアプリケーションを実行しているユーザから確認を得なければなりません。
5.3. HMAC-MD5 and MD5 Weaknesses
5.3. HMAC-MD5とMD5弱点
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]のセキュリティに影響を与えません。
5.4. Security of cast5CBC
5.4. cast5CBCのセキュリティ
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
三重のDES、およびRC4のような確立したアルゴリズムと比べて、cast5CBC暗号化アルゴリズムは比較的新しいです。 それにもかかわらず、SPKM-3のためのMANDATORY C-ALGとしてのcast5CBCの選択は賢明です。 cast5CBCアルゴリズムは256ビットのcast6CBC[RFC2612]アルゴリズムが基づいている128ビットのアルゴリズムです。 米国米国商務省標準技術局(NIST)で、どんな知られている主要であるか小さい方の「セキュリティ相違」も持っていなくて、cast6CBCアルゴリズムが「高いセキュリティマージン」[AES]を持っていると判断されました。 NISTはいくつかの脆弱性に注意しました。
Eisler Standards Track [Page 18] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[18ページ]。
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]ネッシュバタル、J.、バーカー、E.、ダドソン、D.、ドーキン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研究所のCryptoBytes、第2巻、No.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.
[効率] 電子フロンティア財団、ジョン・ギルモア(エディタ)(1998)。 「Crackingデス:」 「暗号化研究、盗聴政治、およびチップデザインのシークレット」とオライリーと仲間、ISBN1565925203
[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)を数に割り当てました。 「ネットワークManagement Parameters」 http://www.isi.edu/in- smi注意/iana/課題/番号
[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:」 . 「ディフィー-ヘルマンは協定規格、バージョン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.
w.w.[PKIX]Housley、R.、フォード、ポーク、D.、「X.509公開鍵基盤の証明書とCRLが輪郭を描くインターネット」が一人で生活して、進行中で働いています。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
[RFC1831]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、1995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation
Standard", RFC 1832, August 1995.
[RFC1832]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
Eisler Standards Track [Page 19] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[19ページ]。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2203] アイスラーとM.とチウとA.とL.の御柳もどき、「RPCSEC_GSSプロトコル仕様」、RFC2203、1997年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
C.、「簡単な公開カギGSS-APIメカニズム(SPKM)」、RFC2025 1996年10月の[RFC2025]アダムス。
[RFC2078] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[RFC2078] リン、J.、「一般的なセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、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.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
May 1997.
[RFC2144]アダムス(C.、「キャスト-128暗号化アルゴリズム」、RFC2144)は1997がそうするかもしれません。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2279]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
[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インチ、RFC2437、10月1998日
[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.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。
[RFC2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption
Algorithm", RFC 2612, June 1999.
[RFC2612] アダムスとC.とJ.ギルクリスト、「キャスト-256暗号化アルゴリズム」、RFC2612、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情報もこれと他の技術に関して受け取られるのを見てください。
[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.、Kleiman、S.、ウォルシュ、D.、リヨン、B.(1985。) 「Sunネットワークファイルシステムの設計と実装」、1985年の夏のUSENIXの技術的なコンファレンスの議事。
Eisler Standards Track [Page 20] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[20ページ]。
[Schneier] Schneier, B. (1996). "Applied Cryptography," John Wiley &
Sons, Inc., ISBN 0-471-11709-9.
[シュナイアー]シュナイアー、B.(1996。) 「適用された暗号」とジョン・ワイリーと息子Inc.、ISBN0-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.
* このメモはジョン・リンによって書かれたRFC2078からの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.
* このメモはカーライルアダムスによって書かれたRFC2025との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
マイクアイスラーZambeel5565ウィルソン・道路コロラド・スプリングス、CO 80919
Phone: 1-719-599-9026 EMail: mike@eisler.com
以下に電話をしてください。 1-719-599-9026 メールしてください: mike@eisler.com
Eisler Standards Track [Page 21] RFC 2847 LIPKEY June 2000
アイスラーStandardsはLIPKEY2000年6月にRFC2847を追跡します[21ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Eisler Standards Track [Page 22]
アイスラー標準化過程[22ページ]
一覧
スポンサーリンク
