RFC2695 日本語訳
2695 Authentication Mechanisms for ONC RPC. A. Chiu. September 1999. (Format: TXT=39286 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Chiu Request for Comments: 2695 Sun Microsystems Category: Informational September 1999
コメントを求めるワーキンググループA.チウの要求をネットワークでつないでください: 2695年のサン・マイクロシステムズカテゴリ: 情報の1999年9月
Authentication Mechanisms for ONC RPC
ONC RPCのための認証機構
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
ABSTRACT
要約
This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol.
このドキュメントは一般的にONC Remote Procedure Call(ONC RPCバージョン2)プロトコルに関連して使用されて、認証メカニズムがサン・マイクロシステムズで作成した2について説明します。
WARNING
警告
The DH authentication as defined in Section 2 in this document refers to the authentication mechanism with flavor AUTH_DH currently implemented in ONC RPC. It uses the underlying Diffie-Hellman algorithm for key exchange. The DH authentication defined in this document is flawed due to the selection of a small prime for the BASE field (Section 2.5). To avoid the flaw a new DH authentication mechanism could be defined with a larger prime. However, the new DH authentication would not be interoperable with the existing DH authentication.
風味AUTH_DHが現在ONC RPCで実装されている状態で、セクション2で定義されるDH認証は本書では認証機構を示します。 それは主要な交換に基本的なディフィー-ヘルマンアルゴリズムを使用します。 本書では定義されたDH認証は小さい第1の選択のため基地の分野(セクション2.5)に失敗します。 欠点を避けるために、より大きい第1で新しいDH認証機構を定義できました。 しかしながら、新しいDH認証は既存のDH認証で共同利用できないでしょう。
As illustrated in [10], a large number of attacks are possible on ONC RPC system services that use non-secure authentication mechanisms. Other secure authentication mechanisms need to be developed for ONC RPC. RFC 2203 describes the RPCSEC_GSS ONC RPC security flavor, a secure authentication mechanism that enables RPC protocols to use Generic Security Service Application Program Interface (RFC 2078) to provide security services, integrity and privacy, that are independent of the underlying security mechanisms.
[10]で例証されるように、多くの攻撃が非安全な認証機構を使用するONC RPCシステムサービスのときに可能です。他の安全な認証機構は、ONC RPCのために開発される必要があります。 RFC2203はRPCSEC_GSS ONC RPCセキュリティ風味(RPCプロトコルがセキュリティー・サービス、保全、およびプライバシーを提供するのに、Generic Security Service Application Program Interface(RFC2078)を使用するのを可能にしている、基本的なセキュリティー対策から独立している安全な認証機構)について説明します。
Chiu Informational [Page 1] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[1ページ]のRFC2695認証機構
Table of Contents
目次
1. Introduction ............................................... 2
2. Diffie-Hellman Authentication .............................. 2
2.1 Naming .................................................... 3
2.2 DH Authentication Verifiers ............................... 3
2.3 Nicknames and Clock Synchronization ....................... 5
2.4 DH Authentication Protocol Specification .................. 5
2.4.1 The Full Network Name Credential and Verifier (Client) .. 6
2.4.2 The Nickname Credential and Verifier (Client) ........... 8
2.4.3 The Nickname Verifier (Server) .......................... 9
2.5 Diffie-Hellman Encryption ................................. 9
3. Kerberos-based Authentication ............................. 10
3.1 Naming ................................................... 11
3.2 Kerberos-based Authentication Protocol Specification ..... 11
3.2.1 The Full Network Name Credential and Verifier (Client) . 12
3.2.2 The Nickname Credential and Verifier (Client) .......... 14
3.2.3 The Nickname Verifier (Server) ......................... 15
3.2.4 Kerberos-specific Authentication Status Values ......... 15
4. Security Considerations ................................... 16
5. REFERENCES ................................................ 16
6. AUTHOR'S ADDRESS .......................................... 17
7. FULL COPYRIGHT STATEMENT ...................................18
1. 序論… 2 2. ディフィー-ヘルマンAuthentication… 2 2.1 命名します。 3 2.2 DH認証検証… 3 2.3のあだ名と時計同期… 5 2.4 DH認証プロトコル仕様… 5 2.4 .1 完全なネットワーク名資格証明書と検証(クライアント)。 6 2.4 .2 あだ名資格証明書と検証(クライアント)… 8 2.4 .3 あだ名検証(サーバ)… 9 2.5ディフィー-ヘルマンEncryption… 9 3. ケルベロスベースの認証… 10 3.1 命名します。 11 3.2 ケルベロスベースの認証プロトコル仕様… 11 3.2 .1 完全なネットワークは資格証明書と検証(クライアント). 12 3.2.2をあだ名資格証明書と検証(クライアント)と命名します… 14 3.2 .3 あだ名検証(サーバ)… 15 3.2 .4 ケルベロス特有の認証状態値… 15 4. セキュリティ問題… 16 5. 参照… 16 6. 作者のアドレス… 17 7. 完全な著作権宣言文…18
1. Introduction
1. 序論
The ONC RPC protocol provides the fields necessary for a client to identify itself to a service, and vice-versa, in each call and reply message. Security and access control mechanisms can be built on top of this message authentication. Several different authentication protocols can be supported.
ONC RPCプロトコルはクライアントがサービスに身元を明らかにするのに必要な野原を供給します、そして、逆もまた同様です、各呼び出しと応答メッセージで。 この通報認証の上にセキュリティとアクセス管理機構を造ることができます。 いくつかの異なった認証プロトコルをサポートできます。
This document specifies two authentication protocols created by Sun Microsystems that are commonly used: Diffie-Hellman (DH) authentication and Kerberos (Version 4) based authentication.
このドキュメントは一般的に使用されて、認証プロトコルがサン・マイクロシステムズで作成した2を指定します: ディフィー-ヘルマン(DH)の認証とケルベロス(バージョン4)は認証を基礎づけました。
As a prerequisite to reading this document, the reader is expected to be familiar with [1] and [2]. This document uses terminology and definitions from [1] and [2].
このドキュメントを読むことへの前提条件として、読者が[1]と[2]によく知られさせると予想されます。 このドキュメントは[1]と[2]から用語と定義を使用します。
2. Diffie-Hellman Authentication
2. ディフィー-ヘルマンAuthentication
System authentication (defined in [1]) suffers from some problems. It is very UNIX oriented, and can be easily faked (there is no attempt to provide cryptographically secure authentication).
システム認証、([1])で定義されて. それがUNIX非常に指向していることにおけるいくつかの問題に苦しんで、容易に見せかけることができます(暗号で安全な認証を提供する試みが全くありません)。
Chiu Informational [Page 2] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[2ページ]のRFC2695認証機構
DH authentication was created to address these problems. However, it has been compromised [9] due to the selection of a small length for the prime in the ONC RPC implementation. While the information provided here will be useful for implementors to ensure interoperability with existing applications that use DH authentication, it is strongly recommended that new applications use more secure authentication, and that existing applications that currently use DH authentication migrate to more robust authentication mechanisms.
DH認証は、これらのその問題を訴えるために作成されました。しかしながら、それはONC RPC実装における第1の間のわずかな長さの選択による[9]であると感染されました。 作成者がDH認証を使用する既存のアプリケーションで相互運用性を保証するようにここに提供された情報が役に立つ間、新しいアプリケーションが、より安全な認証を使用して、現在DH認証を使用する既存のアプリケーションが、より強健な認証機構にわたることが強く勧められます。
2.1 Naming
2.1 命名
The client is addressed by a simple string of characters instead of by an operating system specific integer. This string of characters is known as the "netname" or network name of the client. The server is not allowed to interpret the contents of the client's name in any other way except to identify the client. Thus, netnames should be unique for every client in the Internet.
クライアントはオペレーティングシステムの特定の整数の代わりにキャラクタの簡単なストリングによって宛てられます。 キャラクタのこのストリングはクライアントの"netname"かネットワーク名として知られています。 クライアントを特定する以外に、サーバはいかなる他の方法でもクライアントの名前のコンテンツを解釈できません。 したがって、インターネットのすべてのクライアントにとって、netnamesはユニークであるべきです。
It is up to each operating system's implementation of DH authentication to generate netnames for its users that insure this uniqueness when they call upon remote servers. Operating systems already know how to distinguish users local to their systems. It is usually a simple matter to extend this mechanism to the network. For example, a UNIX(tm) user at Sun with a user ID of 515 might be assigned the following netname: "unix.515@sun.com". This netname contains three items that serve to insure it is unique. Going backwards, there is only one naming domain called "sun.com" in the Internet. Within this domain, there is only one UNIX(tm) user with user ID 515. However, there may be another user on another operating system, for example VMS, within the same naming domain that, by coincidence, happens to have the same user ID. To insure that these two users can be distinguished we add the operating system name. So one user is "unix.515@sun.com" and the other is "vms.515@sun.com". The first field is actually a naming method rather than an operating system name. It happens that today there is almost a one-to-one correspondence between naming methods and operating systems. If the world could agree on a naming standard, the first field could be the name of that standard, instead of an operating system name.
彼らがリモートサーバを訪問するときこのユニークさを保障するユーザのためにnetnamesを生成するのは各オペレーティングシステムのDH認証の実装まで達しています。 オペレーティングシステムは既に彼らのシステムへの地元のユーザを区別する方法を知ります。通常、このメカニズムをネットワークに広げるのは、簡単な事柄です。 例えば、以下のnetnameは515のユーザIDがあるSunのUNIX(tm)ユーザに割り当てられるかもしれません: " unix.515@sun.com "。 このnetnameはそれがユニークであることを保障するのに役立つ3つの項目を含んでいます。 後方に行って、"sun.com"と呼ばれる1つの命名ドメインしかインターネットにありません。 このドメインの中には、1人のUNIX(tm)ユーザしかユーザID515と共にいません。 しかしながら、別のユーザが別のオペレーティングシステムにいるかもしれません、例えば、VMS、偶然の一致でたまたま同じユーザIDを持っているのと同じ命名ドメインの中で。 これらの2人のユーザを区別できるのを保障するために、私たちはオペレーティングシステム名を加えます。 それで、1人のユーザが" unix.515@sun.com "です、そして、もう片方が" vms.515@sun.com "です。 最初の分野は実際にオペレーティングシステム名よりむしろ命名メソッドです。 メソッドとオペレーティングシステムを命名するとき、今日、1〜1つの通信が偶然ほとんどあります。世界が命名規格に同意できるなら、最初の分野はその規格の名前であるかもしれないでしょうに、オペレーティングシステム名の代わりに。
2.2 DH Authentication Verifiers
2.2 DH認証検証
Unlike System authentication, DH authentication does have a verifier so the server can validate the client's credential (and vice-versa). The contents of this verifier are primarily an encrypted timestamp. The server can decrypt this timestamp, and if it is within an accepted range relative to the current time, then the client must have encrypted it correctly. The only way the client could encrypt
System認証と異なって、サーバがクライアントの資格証明書(逆もまた同様である)を有効にすることができるように、DH認証は検証を持っています。 この検証の内容は主として暗号化されたタイムスタンプです。 サーバはこのタイムスタンプを解読することができます、そして、受け入れられた範囲の中に現在の時間に比例しているなら、クライアントは正しくそれを暗号化したに違いありません。 クライアントが暗号化できた唯一の道
Chiu Informational [Page 3] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[3ページ]のRFC2695認証機構
it correctly is to know the "conversation key" of the RPC session, and if the client knows the conversation key, then it must be the real client.
RPCセッションの「会話キー」を知るために、それは正しくあります、そして、クライアントが会話キーを知っているなら、本当のクライアントであるに違いありません。
The conversation key is a DES [5] key which the client generates and passes to the server in the first RPC call of a session. The conversation key is encrypted using a public key scheme in this first transaction. The particular public key scheme used in DH authentication is Diffie-Hellman [3] with 192-bit keys. The details of this encryption method are described later.
会話キーはクライアントがセッションの最初のRPC呼び出しにおけるサーバに生成して、渡すDES[5]キーです。 会話キーは、この最初のトランザクションに公開鍵体系を使用することで暗号化されています。 DH認証に使用される特定の公開鍵体系は192ビットのキーがあるディフィー-ヘルマン[3]です。 この暗号化メソッドの詳細は後で説明されます。
The client and the server need the same notion of the current time in order for all of this to work, perhaps by using the Network Time Protocol [4]. If network time synchronization cannot be guaranteed, then the client can determine the server's time before beginning the conversation using a time request protocol.
このすべてが扱うように、クライアントとサーバは現在の時間の同じ概念を必要とします、恐らくNetwork Timeプロトコル[4]を使用することによって。 ネットワーク時間同期化を保証できないなら、時間要求プロトコルを使用することで会話を始める前に、クライアントはサーバの時間を決定できます。
The way a server determines if a client timestamp is valid is somewhat complicated. For any other transaction but the first, the server just checks for two things:
サーバが、クライアントタイムスタンプが有効であるかどうか決定する方法はいくらか複雑です。 いかなる他のトランザクションにもかかわらず、1番目に関してはも、サーバは2つのものがないかどうかただチェックします:
(1) the timestamp is greater than the one previously seen from the same client. (2) the timestamp has not expired.
(1) タイムスタンプは以前に同じクライアントから見られたものよりすばらしいです。 (2) タイムスタンプは期限が切れていません。
A timestamp is expired if the server's time is later than the sum of the client's timestamp plus what is known as the client's "ttl" (standing for "time-to-live" - you can think of this as the lifetime for the client's credential). The "ttl" is a number the client passes (encrypted) to the server in its first transaction.
サーバの時間がクライアントのタイムスタンプの合計とクライアントの"ttl"として知られていることより遅いなら、タイムスタンプは満期です。(「生きる時間」を表します--あなたはクライアントの資格証明書のための生涯としてこれを考えることができます)。 "ttl"はクライアントが最初のトランザクションにおけるサーバに通過する(暗号化されます)数です。
In the first transaction, the server checks only that the timestamp has not expired. Also, as an added check, the client sends an encrypted item in the first transaction known as the "ttl verifier" which must be equal to the time-to-live minus 1, or the server will reject the credential. If either check fails, the server rejects the credential with an authentication status of AUTH_BADCRED, however if the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
最初のトランザクションでは、サーバは、タイムスタンプが期限が切れているだけではないのをチェックします。 また、加えられたチェックとして、クライアントが「ttl検証」として知られている1を引いて生きる時間と等しいに違いない最初のトランザクションで暗号化された商品を送るか、またはサーバは資格証明書を拒絶するでしょう。 どちらのチェックも失敗するなら、サーバはAUTH_BADCREDの認証状態で資格証明書を拒絶して、タイムスタンプが見られた前のものより初期であるなら、しかしながら、サーバはAUTH_REJECTEDCREDの認証状態を返します。
The client too must check the verifier returned from the server to be sure it is legitimate. The server sends back to the client the timestamp it received from the client, minus one second, encrypted with the conversation key. If the client gets anything different than this, it will reject it, returning an AUTH_INVALIDRESP authentication status to the user.
クライアントもそれが正統であることを確信しているようにサーバから返された検証をチェックしなければなりません。 サーバはそれがクライアントから受け取ったタイムスタンプ(マイナス1秒)が会話キーで暗号化したクライアントを送り返します。 これとクライアントを何かを異ならせると、AUTH_INVALIDRESP認証状態をユーザに返して、それはそれを拒絶するでしょう。
Chiu Informational [Page 4] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[4ページ]のRFC2695認証機構
2.3 Nicknames and Clock Synchronization
2.3 あだ名と時計同期
After the first transaction, the server's DH authentication subsystem returns in its verifier to the client an integer "nickname" which the client may use in its further transactions instead of passing its netname. The nickname could be an index into a table on the server which stores for each client its netname, decrypted conversation key and ttl.
最初のトランザクションの後に、サーバのDH認証サブシステムは検証でクライアントがnetnameを渡すことの代わりにさらなるトランザクションに使用するかもしれない整数「あだ名」をクライアントに返します。 あだ名は各クライアントのために会話キーであると解読されたnetnameとttlを保存するサーバのテーブルへのインデックスであるかもしれません。
Though they originally were synchronized, the client's and server's clocks can get out of synchronization again. When this happens the server returns to the client an authentication status of AUTH_REJECTEDVERF at which point the client should attempt to resynchronize.
それらは元々連動しましたが、クライアントとサーバの時計は再び同期を出ることができます。 これが起こると、クライアントが、どのポイントを再連動させるのを試みるべきであるかでサーバはAUTH_REJECTEDVERFの認証状態をクライアントに返します。
A client may also get an AUTH_BADCRED error when using a nickname that was previously valid. The reason is that the server's nickname table is a limited size, and it may flush entries whenever it wants. A client should resend its original full name credential in this case and the server will give it a new nickname. If a server crashes, the entire nickname table gets flushed, and all clients will have to resend their original credentials.
また、以前に有効であったあだ名を使用するとき、クライアントはAUTH_BADCRED誤りを得るかもしれません。 理由はサーバのあだ名テーブルが限られたサイズであり、欲しいときはいつも、エントリーを洗い流すかもしれないということです。 クライアントはこの場合オリジナルのフルネームの資格証明書を再送するべきです、そして、サーバは新しいあだ名をそれに与えるでしょう。 サーバがダウンするなら、全体のあだ名テーブルは紅潮するようになります、そして、すべてのクライアントが彼らのオリジナルの資格証明書を再送しなければならないでしょう。
2.4 DH Authentication Protocol Specification
2.4 DH認証プロトコル仕様
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
2種類の資格証明書があります: クライアントが完全なネットワーク名、および. それへのサーバによるクライアントを考えて、それが「あだ名」(まさしく符号のない整数)を使用するものを使用するサーバで最初のトランザクションにfullnameを使用しなければなりません。(サーバはそれであだ名をクライアントに返すでしょう)。 クライアントはサーバでさらなるすべてのトランザクションにあだ名を使用するかもしれません。あだ名を使用するという要件が全くありませんが、性能理由にそれを使用するのは賢明です。
The following definitions are used for describing the protocol:
以下の定義はプロトコルについて説明するのに使用されます:
enum authdh_namekind {
ADN_FULLNAME = 0,
ADN_NICKNAME = 1
};
enum authdh_はADN_FULLNAME=0、ADN_NICKNAME=1をnamekindします。
typedef opaque des_block[8]; /* 64-bit block of encrypted data */
typedef不明瞭なdes_ブロック[8]。 暗号化されたデータ*/の/*64ビットのブロック
const MAXNETNAMELEN = 255; /* maximum length of a netname */
const MAXNETNAMELEN=255。 netname*/の/*最大の長さ
The flavor used for all DH authentication credentials and verifiers is "AUTH_DH", with the numerical value 3. The opaque data constituting the client credential encodes the following structure:
すべてのDH認証資格証明書と検証に使用される風味は数値3がある「AUTH_DH」です。 クライアント資格証明書を構成する不明瞭なデータは以下の構造をコード化します:
Chiu Informational [Page 5] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[5ページ]のRFC2695認証機構
union authdh_cred switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname fullname;
case ADN_NICKNAME:
authdh_nickname nickname;
};
ケースADN_FULLNAME: 組合authdh_信用スイッチ(authdh_namekind namekind)authdh_fullname fullnameケースADN_NICKNAME: (authdh_あだ名あだ名)。
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
クライアント資格証明書に伴う検証を構成する不明瞭なデータは以下の構造をコード化します:
union authdh_verf switch (authdh_namekind namekind) {
case ADN_FULLNAME:
authdh_fullname_verf fullname_verf;
case ADN_NICKNAME:
authdh_nickname_verf nickname_verf;
};
ケースADN_FULLNAME: 組合authdh_verfスイッチ(authdh_namekind namekind)authdh_fullname_verf fullname_verf; _ケースADN_NICKNAME: authdh_あだ名_verfあだ名verf;。
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
サーバによってクライアント要求に対応して返された検証を構成する不明瞭なデータは以下の構造をコード化します:
struct authdh_server_verf;
struct authdh_サーバ_verf。
These structures are described in detail below.
これらの構造は以下で詳細に説明されます。
2.4.1 The Full Network Name Credential and Verifier (Client)
2.4.1 完全なネットワーク名資格証明書と検証(クライアント)
First, the client creates a conversation key for the session. Next, the client fills out the following structure:
まず最初に、クライアントはセッションのために主要な会話を作成します。 次に、クライアントは以下の構造に書き込みます:
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+ | タイムスタンプ| タイムスタンプ| | | | 秒| マイクロ秒| ttl| ttl--1| | 32ビット| 32ビット| 32ビット| 32ビット| +---------------------------------------------------------------+ 0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key for the session, and with an initialization vector of 0. This yields:
分野はXDR(外部データ表現)形式で保存されます。 タイムスタンプは真夜中、1970年1月1日以来の時間をコード化します。 次に、これらの128ビットのデータはDES CBCモードで暗号化されます、セッション、および0の初期化ベクトルのために主要な会話を使用して。 これはもたらされます:
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+ | T| | | | T1 T2| W1| W2| | 32ビット| 32ビット| 32ビット| 32ビット| +---------------------------------------------------------------+ 0 31 63 95 127
Chiu Informational [Page 6] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[6ページ]のRFC2695認証機構
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
T1、T2、W1、およびW2が32ビットの量であり、それらの位置を占める元の量に何らかの通信を持っていますが、適切な復号化において、現在互いで互いに依存しているところ。 T1とT2を包括する64ビットの系列はTによって指示されます。
The full network name credential is represented as follows using XDR notation:
完全なネットワーク名資格証明書は以下の通りXDR記法を使用することで表されます:
struct authdh_fullname {
string name<MAXNETNAMELEN>; /* netname of client */
des_block key; /* encrypted conversation key */
opaque w1[4]; /* W1 */
};
struct authdh_fullnameストリング名前<MAXNETNAMELEN>; クライアント*/des_ブロックキーの/*netname; /*暗号化された会話主要な*/不透明なw1[4];/*W1*/。
The conversation key is encrypted using the "common key" using the ECB mode. The common key is a DES key that is derived from the Diffie-Hellman public and private keys, and is described later.
会話キーは、ECBモードを使用することで「一般的なキー」を使用することで暗号化されています。 一般的なキーはディフィー-ヘルマン公衆と秘密鍵から得られて、後で説明されるDESキーです。
The verifier is represented as follows:
検証は以下の通り表されます:
struct authdh_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
struct authdh_fullname_verf des_ブロックタイムスタンプ; /*T(T1とT2の64ビット)*/不透明なw2[4];/*W2*/。
Note that all of the encrypted quantities (key, w1, w2, timestamp) in the above structures are opaque.
上の構造の暗号化された量(キー、w1、w2、タイムスタンプ)のすべてが不透明であることに注意してください。
The fullname credential and its associated verifier together contain the network name of the client, an encrypted conversation key, the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
fullname資格証明書と一緒にその関連検証はttlよりそれほど1であるクライアント、暗号化された会話キー、ttl、タイムスタンプ、およびttl検証のネットワーク名を含んでいます。 ttlは実際に資格証明書のための生涯です。 サーバは現在のサーバ時間が時間がタイムスタンプで示した“within"とttlであるなら資格証明書を受け入れるでしょう。 さもなければ、サーバはAUTH_BADCREDの認証状態で資格証明書を拒絶します。 要求が再演されないのを保障する1つの方法はサーバが、タイムスタンプがそれが最初のトランザクションでないなら見られた前のものよりすばらしいと主張するだろうことです。 タイムスタンプが見られた前のものより初期であるなら、サーバはAUTH_REJECTEDCREDの認証状態を返します。
The server returns a authdh_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current conversation.
サーバはauthdh_サーバ_verf構造を返します。(それは、以下で詳細に説明されます)。 この構造は「あだ名」を含んでいます。(それは、現在の会話におけるその後の要求に使用されるかもしれません)。
Chiu Informational [Page 7] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[7ページ]のRFC2695認証機構
2.4.2 The Nickname Credential and Verifier (Client)
2.4.2 あだ名資格証明書と検証(クライアント)
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
1番目に続くトランザクションでは、クライアントは効率により短いあだ名資格証明書と検証を使用するかもしれません。 まず最初に、クライアントは以下の構造に書き込みます:
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
+-------------------------------+ | タイムスタンプ| タイムスタンプ| | 秒| マイクロ秒| | 32ビット| 32ビット| +-------------------------------+ 0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
分野はXDR(外部データ表現)形式で保存されます。 そして、セッションのために主要な会話を使用して、これらの64ビットのデータはDES ECBモードで暗号化されます。 これはもたらされます:
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
+-------------------------------+ | (T1) | (T2) | | T| | 64ビット| +-------------------------------+ 0 31 63
The nickname credential is represented as follows using XDR notation:
あだ名資格証明書は以下の通りXDR記法を使用することで表されます:
struct authdh_nickname {
unsigned int nickname; /* nickname returned by server */
};
未署名のintあだ名; /*あだ名がサーバ*/で返したstruct authdh_あだ名。
The nickname verifier is represented as follows using XDR notation:
あだ名検証は以下の通りXDR記法を使用することで表されます:
struct authdh_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
struct authdh_は、/*が*/のゼロを合わせるように設定したdes_ブロックタイムスタンプ(/*T(T1とT2の64ビット)*/不透明なw[4])と_verfを愛称で呼びます。
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the request using the fullname credential.
あだ名資格証明書はいくつかの理由によるサーバによる廃棄物であるかもしれません。 AUTH_BADCREDの認証状態は、あだ名がもう有効でないことを示します。 クライアントは、fullname資格証明書を使用することで要求を再試行するべきです。 AUTH_REJECTEDVERFは、あだ名検証が有効でないことを示します。 一方、クライアントは、fullname資格証明書を使用することで要求を再試行するべきです。
Chiu Informational [Page 8] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[8ページ]のRFC2695認証機構
2.4.3 The Nickname Verifier (Server)
2.4.3 あだ名検証(サーバ)
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
サーバは資格証明書を決して返しません。 それは1種類の検証だけ、すなわち、あだ名検証を返します。 これには、以下のXDR表現があります:
struct authdh_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
struct authdh_サーバ_verf*des_ブロックタイムスタンプ_verf; /*タイムスタンプ検証(暗号化される)*/未署名のintあだ名;/新しいクライアントあだ名(非暗号化した)*/。
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
タイムスタンプ検証はまさにクライアントあだ名資格証明書と同じように組み立てられます。 サーバは、クライアントが1秒を引いて送った値にタイムスタンプ値を設定して、会話キーを使用しながら、DES ECBモードでそれを暗号化します。 また、サーバは、清算取引(非暗号化した)に使用されるためにあだ名をクライアントに送ります。
2.5 Diffie-Hellman Encryption
2.5 ディフィー-ヘルマンEncryption
In this scheme, there are two constants "BASE" and "MODULUS" [3]. The particular values Sun has chosen for these for the DH authentication protocol are:
この体系には、2の定数「ベース」と「係数」[3]があります。 SunがDH認証プロトコルのためのこれらに選んだ特定の値は以下の通りです。
const BASE = 3;
const MODULUS = "d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b";
const基地=3。 const MODULUSは"d4a0ba0250b6fd2ec626e7efd637df76c716e22d0944b88b"と等しいです。
Note that the modulus is represented above as a hexadecimal string.
係数が16進ストリングとして上に表されることに注意してください。
The way this scheme works is best explained by an example. Suppose there are two people "A" and "B" who want to send encrypted messages to each other. So, A and B both generate "secret" keys at random which they do not reveal to anyone. Let these keys be represented as SK(A) and SK(B). They also publish in a public directory their "public" keys. These keys are computed as follows:
例でこの体系がうまくいく方法を説明するのは最も良いです。 暗号化メッセージを互いに送りたがっている2人の人「A」と「B」がいると仮定してください。 それで、AとBはともに、無作為に、「秘密」のキーに彼らがだれにも明らかにしないものを生成します。 SK(A)とSK(B)としてこれらのキーを表させてください。 また、彼らは公共のディレクトリで自分達の「公共」のキーを発行します。 これらのキーは以下の通り計算されます:
PK(A) = ( BASE ** SK(A) ) mod MODULUS
PK(B) = ( BASE ** SK(B) ) mod MODULUS
PK(A)がモッズMODULUS PK(B)=と等しい、(基地の**SK(A))(基地**SK(B) )モッズMODULUS
The "**" notation is used here to represent exponentiation. Now, both A and B can arrive at the "common" key between them, represented here as CK(A, B), without revealing their secret keys.
」 記法がここで使用されている**は羃法を表します。 今、それらの秘密鍵を明らかにしないで、AとBの両方がCK(A、B)としてここに表されたそれらの間の「一般的な」キーに到着できます。
Chiu Informational [Page 9] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[9ページ]のRFC2695認証機構
A computes:
Aは計算されます:
CK(A, B) = ( PK(B) ** SK(A)) mod MODULUS
CK(A、B)はモッズMODULUSと等しいです(PK(B)**SK(A))。
while B computes:
Bは計算されますが:
CK(A, B) = ( PK(A) ** SK(B)) mod MODULUS
CK(A、B)が等しい、(PK(A)**SK(B))モッズMODULUS
These two can be shown to be equivalent:
相当しているようにこれらの2を示すことができます:
(PK(B) ** SK(A)) mod MODULUS = (PK(A) ** SK(B)) mod MODULUS
(PK(B)**SK(A))モッズMODULUSが等しい、(PK(A)**SK(B))モッズMODULUS
We drop the "mod MODULUS" parts and assume modulo arithmetic to simplify things:
私たちは、「モッズMODULUS」の部品を下げて、モジュロ演算がものを簡素化すると思います:
PK(B) ** SK(A) = PK(A) ** SK(B)
PK(B)**SK(A)はPK(A)**SKと等しいです。(B)
Then, replace PK(B) by what B computed earlier and likewise for PK(A).
そして、Bが、より早く計算したことと同様にPK(A)のためにPK(B)を取り替えてください。
(BASE ** SK(B)) ** SK(A) = (BASE ** SK(A)) ** SK(B)
(ベース**SK(B))**SK(A)は**SKと等しいです(ベース**SK(A))。(B)
which leads to:
どれが以下のことを導きますか?
BASE ** (SK(A) * SK(B)) = BASE ** (SK(A) * SK(B))
**を基礎づけてください、(SK(A)*SK(B))はベース**と等しいです。(SK(A)*SK(B))
This common key CK(A, B) is not used to encrypt the timestamps used in the protocol. Rather, it is used only to encrypt a conversation key which is then used to encrypt the timestamps. The reason for doing this is to use the common key as little as possible, for fear that it could be broken. Breaking the conversation key is a far less damaging, since conversations are relatively short-lived.
この一般的な主要なCK(A、B)は、プロトコルに使用されるタイムスタンプを暗号化するのに使用されません。 むしろ、それは使用されますが、次にタイムスタンプを暗号化するのに使用される会話キーを暗号化します。 これをする理由はできるだけ少ししか一般的なキーを使用しないことです、それが壊されるかもしれないという恐れによって。 会話が比較的短命であるので、会話キーを壊すのは、はるかに少ない破損です。
The conversation key is encrypted using 56-bit DES keys, yet the common key is 192 bits. To reduce the number of bits, 56 bits are selected from the common key as follows. The middle-most 8-bytes are selected from the common key, and then parity is added to the lower order bit of each byte, producing a 56-bit key with 8 bits of parity.
会話キーが56ビットのDESキーを使用することで暗号化されている、しかし、一般的なキーは192ビットです。 ビットの数を減少させるために、56ビットは以下の一般的なキーから選択されます。 最も中央の8バイトは一般的なキーから選択されます、そして、次に、同等はそれぞれのバイトの下層階級ビットに加えられます、同等の8ビットで56ビットのキーを生産して。
Only 48 bits of the 8-byte conversation key are used in the DH Authentication scheme. The least and most significant bits of each byte of the conversation key are unused.
8バイトの会話キーの48ビットだけがDH Authentication体系に使用されます。 会話キーのそれぞれのバイトの最少と最上位ビットは未使用です。
3. Kerberos-based Authentication
3. ケルベロスベースの認証
Conceptually, Kerberos-based authentication is very similar to DH authentication. The major difference is, Kerberos-based authentication takes advantage of the fact that Kerberos tickets have
概念的に、ケルベロスベースの認証はDH認証と非常に同様です。 主要な違いがあって、ケルベロスベースの認証はケルベロスチケットが持っている事実を利用します。
Chiu Informational [Page 10] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[10ページ]のRFC2695認証機構
encoded in them the client name and the conversation key. This RFC does not describe Kerberos name syntax, protocols and ticket formats. The reader is referred to [6], [7], and [8].
それらでは、クライアント名と会話キーをコード化しました。 このRFCはケルベロス名前構文、プロトコル、およびチケット形式について説明しません。 読者は[6]、[7]、および[8]を参照されます。
3.1 Naming
3.1 命名
A Kerberos name contains three parts. The first is the principal name, which is usually a user's or service's name. The second is the instance, which in the case of a user is usually NULL. Some users may have privileged instances, however, such as root or admin. In the case of a service, the instance is the name of the machine on which it runs; that is, there can be an NFS service running on the machine ABC, which is different from the NFS service running on the machine XYZ. The third part of a Kerberos name is the realm. The realm corresponds to the Kerberos service providing authentication for the principal. When writing a Kerberos name, the principal name is separated from the instance (if not NULL) by a period, and the realm (if not the local realm) follows, preceded by an "@" sign. The following are examples of valid Kerberos names:
ケルベロス名は3つの部品を含んでいます。 1番目は主要な名前です。(通常、その名前はユーザかサービスの名前です)。 2番目はインスタンスです。(通常、そのインスタンスはユーザの場合でNULLです)。 しかしながら、根やアドミンのように特権があるインスタンスを持っているユーザもいるかもしれません。 サービスの場合では、インスタンスはそれが稼働するマシンの名前です。 すなわち、マシンXYZの上で作業するNFSサービスと異なったマシンABCの上で作業するNFSサービスがあることができます。 ケルベロス名の3番目の部分は分野です。 分野は主体のための認証を提供するケルベロスサービスに対応しています。 ケルベロス名を書くとき、主要な名前は期間までにインスタンス(まして、NULL)と切り離されます、そして、分野(まして、地方の分野)は続きます、"@"サインが先行して。 ↓これは妥当なケルベロス名に関する例です:
billb
jis.admin
srz@lcs.mit.edu
treese.root@athena.mit.edu
billb jis.admin srz@lcs.mit.edu treese.root@athena.mit.edu
3.2 Kerberos-based Authentication Protocol Specification
3.2 ケルベロスベースの認証プロトコル仕様
The Kerberos-based authentication protocol described is based on Kerberos version 4.
説明されたケルベロスベースの認証プロトコルはケルベロスバージョン4に基づいています。
There are two kinds of credentials: one in which the client uses its full network name, and one in which it uses its "nickname" (just an unsigned integer) given to it by the server. The client must use its fullname in its first transaction with the server, in which the server will return to the client its nickname. The client may use its nickname in all further transactions with the server. There is no requirement to use the nickname, but it is wise to use it for performance reasons.
2種類の資格証明書があります: クライアントが完全なネットワーク名、および. それへのサーバによるクライアントを考えて、それが「あだ名」(まさしく符号のない整数)を使用するものを使用するサーバで最初のトランザクションにfullnameを使用しなければなりません。(サーバはそれであだ名をクライアントに返すでしょう)。 クライアントはサーバでさらなるすべてのトランザクションにあだ名を使用するかもしれません。あだ名を使用するという要件が全くありませんが、性能理由にそれを使用するのは賢明です。
The following definitions are used for describing the protocol:
以下の定義はプロトコルについて説明するのに使用されます:
enum authkerb4_namekind {
AKN_FULLNAME = 0,
AKN_NICKNAME = 1
};
enum authkerb4_はAKN_FULLNAME=0、AKN_NICKNAME=1をnamekindします。
Chiu Informational [Page 11] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[11ページ]のRFC2695認証機構
The flavor used for all Kerberos-based authentication credentials and verifiers is "AUTH_KERB4", with numerical value 4. The opaque data constituting the client credential encodes the following structure:
すべてのケルベロスベースの認証資格証明書と検証に使用される風味は「数値4があるAUTH_KERB4"」です。 クライアント資格証明書を構成する不明瞭なデータは以下の構造をコード化します:
union authkerb4_cred switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname fullname;
case AKN_NICKNAME:
authkerb4_nickname nickname;
};
ケースAKN_FULLNAME: 組合authkerb4_信用スイッチ(authkerb4_namekind namekind)authkerb4_fullname fullnameケースAKN_NICKNAME: (authkerb4_あだ名あだ名)。
The opaque data constituting a verifier that accompanies a client credential encodes the following structure:
クライアント資格証明書に伴う検証を構成する不明瞭なデータは以下の構造をコード化します:
union authkerb4_verf switch (authkerb4_namekind namekind) {
case AKN_FULLNAME:
authkerb4_fullname_verf fullname_verf;
case AKN_NICKNAME:
authkerb4_nickname_verf nickname_verf;
};
ケースAKN_FULLNAME: 組合authkerb4_verfスイッチ(authkerb4_namekind namekind)authkerb4_fullname_verf fullname_verf; _ケースAKN_NICKNAME: authkerb4_あだ名_verfあだ名verf;。
The opaque data constituting a verifier returned by a server in response to a client request encodes the following structure:
サーバによってクライアント要求に対応して返された検証を構成する不明瞭なデータは以下の構造をコード化します:
struct authkerb4_server_verf;
struct authkerb4_サーバ_verf。
These structures are described in detail below.
これらの構造は以下で詳細に説明されます。
3.2.1 The Full Network Name Credential and Verifier (Client)
3.2.1 完全なネットワーク名資格証明書と検証(クライアント)
First, the client must obtain a Kerberos ticket from the Kerberos Server. The ticket contains a Kerberos session key, which will become the conversation key. Next, the client fills out the following structure:
まず最初に、クライアントはケルベロスServerからケルベロスチケットを得なければなりません。チケットはケルベロスセッションキーを含んでいます。(それは、会話キーになるでしょう)。 次に、クライアントは以下の構造に書き込みます:
+---------------------------------------------------------------+
| timestamp | timestamp | | |
| seconds | micro seconds | ttl | ttl - 1 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+ | タイムスタンプ| タイムスタンプ| | | | 秒| マイクロ秒| ttl| ttl--1| | 32ビット| 32ビット| 32ビット| 32ビット| +---------------------------------------------------------------+ 0 31 63 95 127
The fields are stored in XDR (external data representation) format. The timestamp encodes the time since midnight, January 1, 1970. "ttl" is identical in meaning to the corresponding field in Diffie- Hellman authentication: the credential "time-to-live" for the
分野はXDR(外部データ表現)形式で保存されます。 タイムスタンプは真夜中、1970年1月1日以来の時間をコード化します。 "ttl"は意味がディフィーのヘルマンの認証における対応する分野と同じです: 資格証明「生きる時間」
Chiu Informational [Page 12] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[12ページ]のRFC2695認証機構
conversation being initiated. These 128 bits of data are then encrypted in the DES CBC mode, using the conversation key, and with an initialization vector of 0. This yields:
開始される会話。 次に、これらの128ビットのデータはDES CBCモードで暗号化されます、会話キーを使用して、0の初期化ベクトルで。 これはもたらされます:
+---------------------------------------------------------------+
| T | | |
| T1 T2 | W1 | W2 |
| 32 bits | 32 bits | 32 bits | 32 bits |
+---------------------------------------------------------------+
0 31 63 95 127
+---------------------------------------------------------------+ | T| | | | T1 T2| W1| W2| | 32ビット| 32ビット| 32ビット| 32ビット| +---------------------------------------------------------------+ 0 31 63 95 127
where T1, T2, W1, and W2 are all 32-bit quantities, and have some correspondence to the original quantities occupying their positions, but are now interdependent on each other for proper decryption. The 64 bit sequence comprising T1 and T2 is denoted by T.
T1、T2、W1、およびW2が32ビットの量であり、それらの位置を占める元の量に何らかの通信を持っていますが、適切な復号化において、現在互いで互いに依存しているところ。 T1とT2を包括する64ビットの系列はTによって指示されます。
The full network name credential is represented as follows using XDR notation:
完全なネットワーク名資格証明書は以下の通りXDR記法を使用することで表されます:
struct authkerb4_fullname {
opaque ticket<>; /* kerberos ticket for the server */
opaque w1[4]; /* W1 */
};
struct authkerb4_fullname不透明なチケット<>; サーバ*/不透明なw1[4]の/*kerberosチケット;/*W1*/。
The verifier is represented as follows:
検証は以下の通り表されます:
struct authkerb4_fullname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w2[4]; /* W2 */
};
struct authkerb4_fullname_verf des_ブロックタイムスタンプ; /*T(T1とT2の64ビット)*/不透明なw2[4];/*W2*/。
Note that all of the client-encrypted quantities (w1, w2, timestamp) in the above structures are opaque. The client does not encrypt the Kerberos ticket for the server.
上の構造のクライアントによって暗号化された量(w1、w2、タイムスタンプ)のすべてが不透明であることに注意してください。 クライアントはサーバのケルベロスチケットを暗号化しません。
The fullname credential and its associated verifier together contain the Kerberos ticket (which contains the client name and the conversation key), the ttl, a timestamp, and a ttl verifier that is one less than the ttl. The ttl is actually the lifetime for the credential. The server will accept the credential if the current server time is "within" the time indicated in the timestamp plus the ttl. Otherwise, the server rejects the credential with an authentication status of AUTH_BADCRED. One way to insure that requests are not replayed would be for the server to insist that timestamps are greater than the previous one seen, unless it is the first transaction. If the timestamp is earlier than the previous one seen, the server returns an authentication status of AUTH_REJECTEDCRED.
fullname資格証明書と一緒にその関連検証はケルベロスチケット(クライアント名と会話キーを含む)、ttl、タイムスタンプ、およびttlよりそれほど1であるttl検証を含んでいます。 ttlは実際に資格証明書のための生涯です。 サーバは現在のサーバ時間が時間がタイムスタンプで示した“within"とttlであるなら資格証明書を受け入れるでしょう。 さもなければ、サーバはAUTH_BADCREDの認証状態で資格証明書を拒絶します。 要求が再演されないのを保障する1つの方法はサーバが、タイムスタンプがそれが最初のトランザクションでないなら見られた前のものよりすばらしいと主張するだろうことです。 タイムスタンプが見られた前のものより初期であるなら、サーバはAUTH_REJECTEDCREDの認証状態を返します。
Chiu Informational [Page 13] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[13ページ]のRFC2695認証機構
The server returns a authkerb4_server_verf structure, which is described in detail below. This structure contains a "nickname", which may be used for subsequent requests in the current session.
サーバはauthkerb4_サーバ_verf構造を返します。(それは、以下で詳細に説明されます)。 この構造は「あだ名」を含んでいます。(それは、現在のセッションにおけるその後の要求に使用されるかもしれません)。
3.2.2 The Nickname Credential and Verifier (Client)
3.2.2 あだ名資格証明書と検証(クライアント)
In transactions following the first, the client may use the shorter nickname credential and verifier for efficiency. First, the client fills out the following structure:
1番目に続くトランザクションでは、クライアントは効率により短いあだ名資格証明書と検証を使用するかもしれません。 まず最初に、クライアントは以下の構造に書き込みます:
+-------------------------------+
| timestamp | timestamp |
| seconds | micro seconds |
| 32 bits | 32 bits |
+-------------------------------+
0 31 63
+-------------------------------+ | タイムスタンプ| タイムスタンプ| | 秒| マイクロ秒| | 32ビット| 32ビット| +-------------------------------+ 0 31 63
The fields are stored in XDR (external data representation) format. These 64 bits of data are then encrypted in the DES ECB mode, using the conversation key for the session. This yields:
分野はXDR(外部データ表現)形式で保存されます。 そして、セッションのために主要な会話を使用して、これらの64ビットのデータはDES ECBモードで暗号化されます。 これはもたらされます:
+-------------------------------+
| (T1) | (T2) |
| T |
| 64 bits |
+-------------------------------+
0 31 63
+-------------------------------+ | (T1) | (T2) | | T| | 64ビット| +-------------------------------+ 0 31 63
The nickname credential is represented as follows using XDR notation:
あだ名資格証明書は以下の通りXDR記法を使用することで表されます:
struct authkerb4_nickname {
unsigned int nickname; /* nickname returned by server */
};
未署名のintあだ名; /*あだ名がサーバ*/で返したstruct authkerb4_あだ名。
The nickname verifier is represented as follows using XDR notation:
あだ名検証は以下の通りXDR記法を使用することで表されます:
struct authkerb4_nickname_verf {
des_block timestamp; /* T (the 64 bits of T1 and T2) */
opaque w[4]; /* Set to zero */
};
struct authkerb4_は、/*が*/のゼロを合わせるように設定したdes_ブロックタイムスタンプ(/*T(T1とT2の64ビット)*/不透明なw[4])と_verfを愛称で呼びます。
The nickname credential may be reject by the server for several reasons. An authentication status of AUTH_BADCRED indicates that the nickname is no longer valid. The client should retry the request using the fullname credential. AUTH_REJECTEDVERF indicates that the nickname verifier is not valid. Again, the client should retry the
あだ名資格証明書はいくつかの理由によるサーバによる廃棄物であるかもしれません。 AUTH_BADCREDの認証状態は、あだ名がもう有効でないことを示します。 クライアントは、fullname資格証明書を使用することで要求を再試行するべきです。 AUTH_REJECTEDVERFは、あだ名検証が有効でないことを示します。 一方、クライアントは再試行するべきです。
Chiu Informational [Page 14] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[14ページ]のRFC2695認証機構
request using the fullname credential. AUTH_TIMEEXPIRE indicates that the session's Kerberos ticket has expired. The client should initiate a new session by obtaining a new Kerberos ticket.
fullname資格証明書を使用することで、要求します。 AUTH_TIMEEXPIREは、セッションのケルベロスチケットが期限が切れたのを示します。 クライアントは、新しいケルベロスチケットを得ることによって、新しいセッションを開始するべきです。
3.2.3 The Nickname Verifier (Server)
3.2.3 あだ名検証(サーバ)
The server never returns a credential. It returns only one kind of verifier, i.e., the nickname verifier. This has the following XDR representation:
サーバは資格証明書を決して返しません。 それは1種類の検証だけ、すなわち、あだ名検証を返します。 これには、以下のXDR表現があります:
struct authkerb4_server_verf {
des_block timestamp_verf; /* timestamp verifier (encrypted) */
unsigned int nickname; /* new client nickname (unencrypted) */
};
struct authkerb4_サーバ_verf*des_ブロックタイムスタンプ_verf; /*タイムスタンプ検証(暗号化される)*/未署名のintあだ名;/新しいクライアントあだ名(非暗号化した)*/。
The timestamp verifier is constructed in exactly the same way as the client nickname credential. The server sets the timestamp value to the value the client sent minus one second and encrypts it in DES ECB mode using the conversation key. The server also sends the client a nickname to be used in future transactions (unencrypted).
タイムスタンプ検証はまさにクライアントあだ名資格証明書と同じように組み立てられます。 サーバは、クライアントが1秒を引いて送った値にタイムスタンプ値を設定して、会話キーを使用しながら、DES ECBモードでそれを暗号化します。 また、サーバは、清算取引(非暗号化した)に使用されるためにあだ名をクライアントに送ります。
3.2.4 Kerberos-specific Authentication Status Values
3.2.4 ケルベロス特有の認証状態値
The server may return to the client one of the following errors in the authentication status field:
サーバは認証状態分野で以下の誤りの1つをクライアントに返すかもしれません:
enum auth_stat {
...
/*
* kerberos errors
*/
AUTH_KERB_GENERIC = 8, /* Any Kerberos-specific error other
than the following */
AUTH_TIMEEXPIRE = 9, /* The client's ticket has expired */
AUTH_TKT_FILE = 10, /* The server was unable to find the
ticket file. The client should
create a new session by obtaining a
new ticket */
AUTH_DECODE = 11, /* The server is unable to decode the
authenticator of the client's ticket */
AUTH_NET_ADDR = 12 /* The network address of the client
does not match the address contained
in the ticket */
… /**は誤り*/AUTH_KERB_GENERIC=8をkerberosします、/*。以下の*/AUTH_TIMEEXPIRE以外のどんなケルベロス特有の誤りも9、/*と等しいです。enum auth_スタット、クライアントのチケットは*/AUTH_TKT_FILE=10を吐き出しました、サーバがチケットファイルを見つけることができなかった/*; クライアントは新しいチケット*/AUTH_DECODE=11、/*を得るのによるサーバがアドレスがチケット*/に含んだマッチではなく、クライアントのネットワーク・アドレスがするクライアントのチケット*/AUTH_ネット_ADDR=12/*の固有識別文字を解読できない新しいセッションを作成するべきです。
/* and more to be defined */
};
定義された*/である/*とその他、。
Chiu Informational [Page 15] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[15ページ]のRFC2695認証機構
4. Security Considerations
4. セキュリティ問題
The DH authentication mechanism and the Kerberos V4 authentication mechanism are described in this document only for informational purposes.
DH認証機構とケルベロスV4認証機構は本書では情報の目的のためだけに説明されます。
In addition to the weakness pointed out earlier in this document (see WARNING on page 1), the two security mechanisms described herein lack the support for integrity and privacy data protection. It is strongly recommended that new applications use more secure mechanisms, and that existing applications migrate to more robust mechanisms.
より早く本書では(1ページのWARNINGを見る)指摘された弱点に加えて、ここに説明された2台のセキュリティー対策が保全とプライバシー・データ保護のサポートを欠いています。 新しいアプリケーションが、より安全なメカニズムを使用して、既存のアプリケーションが、より強健なメカニズムにわたることが強く勧められます。
The RPCSEC_GSS ONC RPC security flavor, specified in RFC 2203, allows applications built on top of RPC to access security mechanisms that adhere to the GSS-API specification. It provides a GSS-API based security framework that allows for strong security mechanisms. RFC 1964 describes the Kerberos Version 5 GSS-API security mechanism which provides integrity and privacy, in addition to authentication. RFC 2623 [14] describes how Kerberos V5 is pluggued into RPCSEC_GSS, and how the Version 2 and Version 3 of the NFS protocol use Kerberos V5 via RPCSEC_GSS. The RPCSEC_GSS/GSS-API/Kerberos-V5 stack provides a robust security mechanism for applications that require strong protection.
RFC2203で指定されたRPCSEC_GSS ONC RPCセキュリティ風味で、RPCの上で組立てられたアプリケーションはGSS-API仕様を固く守るセキュリティー対策にアクセスできます。 それは強いセキュリティー対策を考慮するベースのGSS-APIセキュリティフレームワークを提供します。RFC1964は保全とプライバシーを提供するケルベロスバージョン5GSS-APIセキュリティー対策について説明します、認証に加えて。 RFC2623[14]は、ケルベロスV5がどのようにRPCSEC_GSSにplugguedされるか、そして、NFSプロトコルのバージョン2とバージョン3がRPCSEC_GSSを通してどのようにケルベロスV5を使用するかを説明します。 ケルベロスRPCSEC_GSS/GSS-API/V5スタックは強い保護を必要とするアプリケーションに強健なセキュリティー対策を提供します。
5. REFERENCES
5. 参照
[1] Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
1831, August 1995.
[1]Srinivasan、R.、「遠隔手続き呼び出しプロトコルバージョン2インチ、RFC1831、1995年8月。」
[2] Srinivasan, R., "XDR: External Data Representation Standard",
RFC 1832, August 1995.
[2]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
[3] Diffie & Hellman, "New Directions in Cryptography", IEEE
Transactions on Information Theory IT-22, November 1976.
[3] ディフィーとヘルマン、「暗号に関する新傾向」、情報理論IT-22でのIEEEトランザクション、1976年11月。
[4] Mills, D., "Network Time Protocol (Version 3)", RFC 1305, March
1992.
[4] 工場、D.、「ネットワーク時間プロトコル(バージョン3)」、RFC1305、1992年3月。
[5] National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standards Publication 46, January
1977.
[5]規格基準局、「データ暗号化規格」、連邦政府の情報処理規格公表46、1月1977日
[6] Miller, S., Neuman, C., Schiller, J. and J. Saltzer, "Section
E.2.1: Kerberos Authentication and Authorization System",
December 1987.
[6] ミラー、S.、ヌーマン、C.、シラー、J.、およびJ.Saltzer、「E.2.1を区分してください」 1987年12月の「ケルベロス認証と承認システム」
Chiu Informational [Page 16] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[16ページ]のRFC2695認証機構
[7] Steiner, J., Neuman, C. and J. Schiller, "Kerberos: An
Authentication Service for Open Network Systems", pp. 191-202 in
Usenix Conference Proceedings, Dallas, Texas, February, 1988.
[7] スタイナー、J.、ヌーマン、C.、およびJ.シラー、「ケルベロス:」 「オープンNetwork SystemsのためのAuthentication Service」、ページ 191-202 Usenix会議の議事録、ダラス(テキサス)1988年2月に。
[8] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[8] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[9] La Macchia, B.A., and Odlyzko, A.M., "Computation of Discrete
Logarithms in Prime Fields", pp. 47-62 in "Designs, Codes and
Cryptography", Kluwer Academic Publishers, 1991.
[9] La Macchia、学士、およびOdlyzko、午前、「素体での離散対数の計算」、ページ 47-62 「デザイン、コード、および暗号」でKluwerのアカデミックな出版社、1991
[10] Cheswick, W.R., and Bellovin, S.M., "Firewalls and Internet
Security," Addison-Wesley, 1995.
[10] チェスウィック、W.R.、Bellovin、S.M.、および「ファイアウォールとインターネットセキュリティ」、アディソン-ウエスリー、1995
[11] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996.
[11] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[12] Linn, J., "Generic Security Service Application Program
Interface, Version 2", RFC 2078, January 1997.
[12] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、1997年1月。」
[13] Eisler, M., Chiu, A., and Ling, L., "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[13] アイスラーとM.とチウ、A.と御柳もどき、L.、「RPCSEC_GSSプロトコル仕様」、RFC2203、1997年9月。
[14] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the
NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623,
June 1999.
[14] アイスラーとM.と「NFSバージョン2とバージョン3安全保障問題とRPCSEC_GSSとケルベロスV5"、RFC2623のNFSプロトコルの使用、1999年6月。」
6. AUTHOR'S ADDRESS
6. 作者のアドレス
Alex Chiu Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
アレックスチウサン・マイクロシステムズ・インク901サンアントニオRoadパロアルト、カリフォルニア 94303
Phone: +1 (650) 786-6465 EMail: alex.chiu@Eng.sun.com
以下に電話をしてください。 +1 (650) 786-6465 メールしてください: alex.chiu@Eng.sun.com
Chiu Informational [Page 17] RFC 2695 Authentication Mechanisms for ONC RPC September 1999
ONC RPC1999年9月のためのチウ情報[17ページ]のRFC2695認証機構
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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機能のための基金は現在、インターネット協会によって提供されます。
Chiu Informational [Page 18]
チウInformationalです。[18ページ]
一覧
スポンサーリンク
