RFC3652 日本語訳
3652 Handle System Protocol (ver 2.1) Specification. S. Sun, S.Reilly, L. Lannom, J. Petrone. November 2003. (Format: TXT=124380 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Sun
Request for Comments: 3652 S. Reilly
Category: Informational L. Lannom
J. Petrone
CNRI
November 2003
コメントを求めるワーキンググループS.Sun要求をネットワークでつないでください: 3652秒間ライリーCategory: 情報のL.Lannom J.Petrone CNRI2003年11月
Handle System Protocol (ver 2.1) Specification
システムプロトコル(ver2.1)仕様を扱ってください。
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
IESG Note
IESG注意
Several groups within the IETF and IRTF have discussed the Handle System and its relationship to existing systems of identifiers. The IESG wishes to point out that these discussions have not resulted in IETF consensus on the described Handle System, nor on how it might fit into the IETF architecture for identifiers. Though there has been discussion of handles as a form of URI, specifically as a URN, these documents describe an alternate view of how namespaces and identifiers might work on the Internet and include characterizations of existing systems which may not match the IETF consensus view.
IETFとIRTFの中のいくつかのグループが識別子の既存のシステムとのHandle Systemとその関係について議論しました。 IESGは、これらの議論が説明されたHandle Systemと、それがどう識別子のためのIETFアーキテクチャに収まるかもしれないかに関するIETFコンセンサスをもたらしていないと指摘したがっています。 ハンドルの議論がURIのフォームとして特にURNとしてありましたが、これらのドキュメントは、名前空間と識別子がインターネットでどう働くかもしれないかに関する代替の意見について説明して、IETF大多数の見解に合わないかもしれない既存のシステムの特殊化を含んでいます。
Abstract
要約
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
Handle Systemは公共のインターネットの上に機密保護している名前解決と管理を許容する汎用グローバル名サービスです。 このドキュメントはクライアントソフトウェアがハンドル解決と管理の両方のためにHandle Systemにアクセスするのに使用されるプロトコルについて説明します。 クライアントソフトウェアがどんな与えられたハンドルの原因となるハンドルサーバも場所を見つけるように、プロトコルは手順を指定します。 また、それはどんなハンドル操作のためのクライアントとサーバの間でも交換されたメッセージを定義します。
Sun, et al. Informational [Page 1] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[1ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Elements. . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Conventions. . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Data Transmission Order. . . . . . . . . . . . . 4
2.1.2. Transport Layer. . . . . . . . . . . . . . . . . 5
2.1.3. Character Case . . . . . . . . . . . . . . . . . 6
2.1.4. Standard String Type: UTF8-String. . . . . . . . 7
2.2. Common Elements. . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Message Envelope . . . . . . . . . . . . . . . . 8
2.2.2. Message Header . . . . . . . . . . . . . . . . . 11
2.2.3. Message Body . . . . . . . . . . . . . . . . . . 17
2.2.4. Message Credential . . . . . . . . . . . . . . . 18
2.3. Message Transmission . . . . . . . . . . . . . . . . . . 20
3. Handle Protocol Operations . . . . . . . . . . . . . . . . . . 21
3.1. Client Bootstrapping . . . . . . . . . . . . . . . . . . 21
3.1.1. Global Handle Registry and its Service
Information. . . . . . . . . . . . . . . . . . . 21
3.1.2. Locating the Handle System Service Component . . 22
3.1.3. Selecting the Responsible Server . . . . . . . . 23
3.2. Query Operation. . . . . . . . . . . . . . . . . . . . . 23
3.2.1. Query Request. . . . . . . . . . . . . . . . . . 24
3.2.2. Successful Query Response. . . . . . . . . . . . 25
3.2.3. Unsuccessful Query Response. . . . . . . . . . . 26
3.3. Error Response from Server . . . . . . . . . . . . . . . 26
3.4. Service Referral . . . . . . . . . . . . . . . . . . . . 27
3.5. Client Authentication. . . . . . . . . . . . . . . . . . 28
3.5.1. Challenge from Server to Client. . . . . . . . . 29
3.5.2. Challenge-Response from Client to Server . . . . 30
3.5.3. Challenge-Response Verification-Request. . . . . 33
3.5.4. Challenge-Response Verification-Response . . . . 33
3.6. Handle Administration. . . . . . . . . . . . . . . . . . 34
3.6.1. Add Handle Value(s). . . . . . . . . . . . . . . 34
3.6.2. Remove Handle Value(s) . . . . . . . . . . . . . 35
3.6.3. Modify Handle Value(s) . . . . . . . . . . . . . 36
3.6.4. Create Handle. . . . . . . . . . . . . . . . . . 37
3.6.5. Delete Handle. . . . . . . . . . . . . . . . . . 39
3.7. Naming Authority (NA) Administration . . . . . . . . . . 40
3.7.1. List Handle(s) under a Naming Authority. . . . . 40
3.7.2. List Sub-Naming Authorities under a Naming
Authority. . . . . . . . . . . . . . . . . . . . 41
3.8. Session and Session Management . . . . . . . . . . . . . 42
3.8.1. Session Setup Request. . . . . . . . . . . . . . 43
3.8.2. Session Setup Response . . . . . . . . . . . . . 46
3.8.3. Session Key Exchange . . . . . . . . . . . . . . 47
3.8.4. Session Termination. . . . . . . . . . . . . . . 48
1. 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 Elementsについて議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . . . . 4 2.1. コンベンション。 . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. データ伝送オーダー。 . . . . . . . . . . . . 4 2.1.2. 層を輸送してください。 . . . . . . . . . . . . . . . . 5 2.1.3. キャラクターケース. . . . . . . . . . . . . . . . . 6 2.1.4。 標準のストリングタイプ: UTF8-ストリング。 . . . . . . . 7 2.2. 一般的なElements。 . . . . . . . . . . . . . . . . . . . . 7 2.2.1. メッセージ封筒. . . . . . . . . . . . . . . . 8 2.2.2。 メッセージヘッダー. . . . . . . . . . . . . . . . . 11 2.2.3。 メッセージ本体. . . . . . . . . . . . . . . . . . 17 2.2.4。 メッセージ資格証明書. . . . . . . . . . . . . . . 18 2.3。 メッセージ送信. . . . . . . . . . . . . . . . . . 20 3。 プロトコル操作. . . . . . . . . . . . . . . . . . 21 3.1を扱ってください。 クライアントブートストラップ法. . . . . . . . . . . . . . . . . . 21 3.1.1。 グローバルなHandle RegistryとそのService情報。 . . . . . . . . . . . . . . . . . . 21 3.1.2. ハンドルシステムサービスの部品. . 22 3.1.3の場所を見つけます。 原因となるサーバ. . . . . . . . 23 3.2を選択します。 操作について質問してください。 . . . . . . . . . . . . . . . . . . . . 23 3.2.1. 要求について質問してください。 . . . . . . . . . . . . . . . . . 24 3.2.2. うまくいっている質問応答。 . . . . . . . . . . . 25 3.2.3. 失敗の質問応答。 . . . . . . . . . . 26 3.3. サーバ. . . . . . . . . . . . . . . 26 3.4からの誤り応答。 紹介. . . . . . . . . . . . . . . . . . . . 27 3.5を修理してください。 クライアント認証。 . . . . . . . . . . . . . . . . . 28 3.5.1. サーバからクライアントまで挑戦してください。 . . . . . . . . 29 3.5.2. クライアントからのサーバ. . . . 30 3.5.3へのチャレンジレスポンス。 チャレンジレスポンス検証要求。 . . . . 33 3.5.4. チャレンジレスポンス検証応答. . . . 33 3.6。 政権を扱ってください。 . . . . . . . . . . . . . . . . . 34 3.6.1. ハンドル価値を高めてください。 . . . . . . . . . . . . . . 34 3.6.2. ハンドル価値. . . . . . . . . . . . . 35 3.6の.3を取り除いてください。 ハンドル価値. . . . . . . . . . . . . 36 3.6の.4を変更してください。 ハンドルを作成してください。 . . . . . . . . . . . . . . . . . 37 3.6.5. ハンドルを削除してください。 . . . . . . . . . . . . . . . . . 39 3.7. 権威(Na)を政権. . . . . . . . . . 40 3.7.1と命名します。 命名権威の下でハンドルを記載してください。 . . . . 40 3.7.2. 命名権威の下でサブ命名当局を記載してください。 . . . . . . . . . . . . . . . . . . . 41 3.8. セッションとセッション管理. . . . . . . . . . . . . 42 3.8.1。 セッションセットアップ要求。 . . . . . . . . . . . . . 43 3.8.2. セッションセットアップ応答. . . . . . . . . . . . . 46 3.8.3。 セッションの主要な交換. . . . . . . . . . . . . . 47 3.8.4。 セッション終了。 . . . . . . . . . . . . . . 48
Sun, et al. Informational [Page 2] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[2ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
4. Implementation Guidelines. . . . . . . . . . . . . . . . . . . 48
4.1. Server Implementation. . . . . . . . . . . . . . . . . . 48
4.2. Client Implementation. . . . . . . . . . . . . . . . . . 49
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. Informative References . . . . . . . . . . . . . . . . . . . . 50
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 52
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 53
4. 実施要綱。 . . . . . . . . . . . . . . . . . . 48 4.1. サーバ実装。 . . . . . . . . . . . . . . . . . 48 4.2. クライアント実装。 . . . . . . . . . . . . . . . . . 49 5. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 49 6. 承認. . . . . . . . . . . . . . . . . . . . . . . 50 7。 有益な参照. . . . . . . . . . . . . . . . . . . . 50 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 52 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 53
1. Overview
1. 概要
The Handle System provides a general-purpose, secured global name service for the Internet. It was originally conceived and described in a paper by Robert Kahn and Robert Wilensky [18] in 1995. The Handle System defines a client server protocol in which client software submits requests via a network to handle servers. Each request describes the operation to be performed on the server. The server will process the request and return a message indicating the result of the operation. This document specifies the protocol for client software to access a handle server for handle resolution and administration. It does not include the description of the protocol used to manage handle servers. A discussion of the management protocol is out of the scope of this document and will be made available in a separate document. The document assumes that readers are familiar with the basic concepts of the Handle System as introduced in the "Handle System Overview" [1], as well as the data model and service definition given in the "Handle System Namespace and Service Definition" [2].
Handle Systemはインターネットのためのグローバル名サービスであることが保証された汎用を提供します。 それは、1995年のロバート・カーンとロバート・ウィレンスキー[18]によって元々、発想されて、論文で説明されました。 Handle Systemはクライアントソフトウェアがサーバを扱うというネットワークを通した要求を提出するクライアントサーバプロトコルを定義します。 各要求は、サーバに実行されるために操作について説明します。サーバは、要求を処理して、操作の結果を示すメッセージを返すでしょう。 クライアントソフトウェアがハンドル解決と管理のためにハンドルサーバにアクセスするように、このドキュメントはプロトコルを指定します。 それはハンドルサーバを管理するのに使用されるプロトコルの記述を含んでいません。 管理プロトコルの議論はこのドキュメントの範囲の外にあって、別々のドキュメントで利用可能にするでしょう。 ドキュメントは、読者が「ハンドルシステム概要」[1]で導入するようにHandle Systemに関する基本概念に詳しいと仮定します、「ハンドルシステム名前空間とサービス定義」[2]で与えられたデータモデルとサービス定義と同様に。
The Handle System consists of a set of service components as defined in [2]. From the client's point of view, the Handle System is a distributed database for handles. Different handles under the Handle System may be maintained by different handle servers at different network locations. The Handle protocol specifies the procedure for a client to locate the responsible handle server of any given handle. It also defines the messages exchanged between the client and server for any handle operation.
Handle Systemは[2]で定義されるように1セットのサービスの部品から成ります。 クライアントの観点から、Handle Systemはハンドルのための分散データベースです。 Handle Systemの下の異なったハンドルは異なったネットワークの位置で異なったハンドルサーバによって維持されるかもしれません。 クライアントがどんな与えられたハンドルの原因となるハンドルサーバも場所を見つけるように、Handleプロトコルは手順を指定します。 また、それはどんなハンドル操作のためのクライアントとサーバの間でも交換されたメッセージを定義します。
Some key aspects of the Handle protocol include:
Handleプロトコルのいくつかの特徴は:
o The Handle protocol supports both handle resolution and
administration. The protocol follows the data and service
model defined in [2].
o Handleプロトコルはハンドル解決と管理の両方をサポートします。 プロトコルは[2]で定義されたデータとサービスモデルに従います。
o A client may authenticate any server response based on the
server's digital signature.
o クライアントはサーバのデジタル署名に基づくどんなサーバ応答も認証するかもしれません。
Sun, et al. Informational [Page 3] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[3ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
o A server may authenticate its client as handle administrator
via the Handle authentication protocol. The Handle
authentication protocol is a challenge-response protocol that
supports both public-key and secret-key based authentication.
o サーバはハンドル管理者としてHandle認証プロトコルでクライアントを認証するかもしれません。 Handle認証プロトコルは公開鍵と秘密鍵の両方がベースの認証であるとサポートするチャレンジレスポンスプロトコルです。
o A session may be established between the client and server so
that authentication information and network resources (e.g.,
TCP connection) may be shared among multiple operations. A
session key can be established to achieve data integrity and
confidentiality.
o セッションは、同時併行処理の中で認証情報とネットワーク資源(例えば、TCP接続)を共有できるようにクライアントとサーバの間で確立されるかもしれません。 データ保全と秘密性を達成するためにセッションキーを設立できます。
o The protocol can be extended to support new operations.
Controls can be used to extend the existing operations. The
protocol is defined to allow future backward compatibility.
o 新しい操作をサポートするためにプロトコルを広げることができます。 既存の操作を広げるのにコントロールを使用できます。 プロトコルは、将来の後方の互換性を許容するために定義されます。
o Distributed service architecture. Support service referral
among different service components.
o 分配されたサービスアーキテクチャ。 異なったサービスコンポーネントの中でサービスが紹介であるとサポートしてください。
o Handles and their data types are based on the ISO-10646
(Unicode 2.0) character set. UTF-8 [3] is the mandated
encoding under the Handle protocol.
o ハンドルとそれらのデータ型はISO-10646(ユニコード2.0)文字集合に基づいています。 UTF-8[3]はHandleプロトコルの下で強制されたコード化です。
The Handle protocol (version 2.1) specified in this document has changed significantly from its earlier versions. These changes are necessary due to changes made in the Handle System data model and the service model. Servers that implement this protocol may continue to support earlier versions of the protocol by checking the protocol version specified in the Message Envelope (see section 2.2.1).
本書では指定されたHandleプロトコル(バージョン2.1)は以前のバージョンからかなり変化しました。 これらの変化がHandle Systemデータモデルとサービスモデルで行われた変更のために必要です。 このプロトコルを実装するサーバは、Message Envelopeで指定されたプロトコルバージョンをチェックすることによってプロトコルの以前のバージョンをサポートし続けるかもしれません(セクション2.2.1を見てください)。
2. Protocol Elements
2. プロトコル要素
2.1. Conventions
2.1. コンベンション
The following conventions are followed by the Handle protocol to ensure interoperability among different implementations.
Handleプロトコルは以下のコンベンションのあとに続いて、異なった実装の中で相互運用性を確実にします。
2.1.1. Data Transmission Order
2.1.1. データ伝送オーダー
The order of transmission of data packets follows the network byte order (also called the Big-Endian [11]). That is, when a data-gram consists of a group of octets, the order of transmission of those octets follows their natural order from left to right and from top to bottom, as they are read in English. For example, in the following diagram, the octets are transmitted in the order they are numbered.
データ・パケットのトランスミッションの注文はネットワークバイトオーダーに続きます。(また、Big-エンディアン[11])と呼ばれます。 すなわち、データグラムが八重奏のグループから成るとき、左から右、それらが英語で上から下まで読まれるとき、それらの八重奏の送信の注文はそれらの自然界の秩序に従います。 例えば、以下のダイヤグラムで、八重奏はオーダーで伝えられて、それらが番号付であるということです。
Sun, et al. Informational [Page 4] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[4ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.-------------------------------.
| 1 | 2 |
|-------------------------------|
| 3 | 4 |
|-------------------------------|
| 5 | 6 |
'-------------------------------'
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .-------------------------------. | 1 | 2 | |-------------------------------| | 3 | 4 | |-------------------------------| | 5 | 6 | '-------------------------------'
If an octet represents a numeric quantity, the left most bit is the most significant bit. For example, the following diagram represents the value 170 (decimal).
八重奏が数値量を表すなら、最も噛み付かれた左は最も重要なビットです。 例えば、以下のダイヤグラムは値170の(小数)を表します。
0 1 2 3 4 5 6 7
.---------------.
|1 0 1 0 1 0 1 0|
'---------------'
0 1 2 3 4 5 6 7 .---------------. |1 0 1 0 1 0 1 0| '---------------'
Similarly, whenever a multi-octet field represents a numeric quantity, the left most bit is the most significant bit and the most significant octet of the whole field is transmitted first.
同様に、マルチ八重奏分野が数値量を表すときはいつも、最も噛み付かれた左は最も重要なビットです、そして、全体の分野の最も重要な八重奏は最初に、伝えられます。
2.1.2. Transport Layer
2.1.2. トランスポート層
The Handle protocol is designed so that messages may be transmitted either as separate data-grams over UDP or as a continuous byte stream via a TCP connection. The recommended port number for both UDP and TCP is 2641.
Handleプロトコルは、UDPの上の別々のデータグラムとして、または、TCP接続を通した連続したバイト・ストリームとしてメッセージを送ることができるように設計されています。 UDPとTCPの両方のためのお勧めのポートナンバーは2641です。
UDP Usage
UDP用法
Messages carried by UDP are restricted to 512 bytes (not including
the IP or UDP header). Longer messages must be fragmented into
UDP packets where each packet carries a proper sequence number in
the Message Envelope (see Section 2.2.1).
UDPによって伝えられたメッセージは512バイトに制限されます(IPかUDPヘッダーを含んでいなくて)。 各パケットがMessage Envelopeで適切な一連番号を運ぶところで(セクション2.2.1を見てください)より長いメッセージをUDPパケットに断片化しなければなりません。
The optimum retransmission policy will vary depending on the
network or server performance, but the following are recommended:
ネットワークかサーバ性能によって、最適な「再-トランスミッション」方針は異なるでしょうが、以下はお勧めです:
o The client should try other servers or service interfaces
before repeating a request to the same server address.
o 同じサーバアドレスに要求を繰り返す前に、クライアントは他のサーバかサービスインタフェースを試みるべきです。
o The retransmission interval should be based on prior
statistics if possible. Overly aggressive retransmission
should be avoided to prevent network congestion. The
recommended retransmission interval is 2-5 seconds.
o できれば、再送信間隔は先の統計に基づくべきです。 ひどく攻撃的な「再-トランスミッション」は、ネットワークの混雑を防ぐために避けられるべきです。 お勧めの再送信間隔は2-5秒です。
Sun, et al. Informational [Page 5] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[5ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
o When transmitting large amounts of data, TCP-friendly
congestion control, such as an interface to the Congestion
Manager [12], should be implemented whenever possible to
avoid unfair consumption of the bandwidth against TCP-based
applications. Details of the congestion control will be
discussed in a separate document.
o 多量のデータを送るとき、TCPベースのアプリケーションに対して帯域幅の不公平な消費を避けるのにおいて可能であるときはいつも、Congestionマネージャ[12]へのインタフェースなどのTCPに優しい輻輳制御は実装されるべきです。 別々のドキュメントで輻輳制御の細部について議論するでしょう。
TCP Usage
TCP用法
Messages under the Handle protocol can be mapped directly into a
TCP byte-stream. However, the size of each message is limited by
the range of a 4-byte unsigned integer. Longer messages may be
fragmented into multiple messages before the transmission and
reassembled at the receiving end.
Handleプロトコルの下におけるメッセージをTCPバイト・ストリームの直接中に写像できます。 しかしながら、それぞれのメッセージのサイズは4バイトの符号のない整数の範囲によって制限されます。 より長いメッセージは、トランスミッションの前に複数のメッセージに断片化されて、犠牲者に組み立て直されるかもしれません。
Several connection management policies are recommended:
いくつかの接続経営政策がお勧めです:
o The server should support multiple connections and should
not block other activities waiting for TCP data.
o サーバは、複数の接続をサポートするべきであり、TCPデータを待つ他の活動を妨げるべきではありません。
o By default, the server should close the connection after
completing the request. However, if the request asks to
keep the connection open, the server should assume that the
client will initiate connection closing.
o デフォルトで、要求を終了した後に、サーバは接続を終えるべきです。 しかしながら、要求が、接続を開くように保つように頼むなら、サーバは、クライアントが接続閉鎖を開始すると仮定するべきです。
2.1.3. Character Case
2.1.3. キャラクターケース
Handles are character strings based on the ISO-10646 character set and must be encoded in UTF-8. By default, handle characters are treated as case-sensitive under the Handle protocol. A handle service, however, may be implemented in such a way that ASCII characters are processed case-insensitively. For example, the Global Handle Registry (GHR) provides a handle service where ASCII characters are processed in a case-insensitive manner. This suggests that ASCII characters in any naming authority are case-insensitive.
ハンドルをISO-10646文字集合に基づく文字列であり、UTF-8でコード化しなければなりません。 デフォルトで、ハンドルキャラクタはHandleプロトコルの下で大文字と小文字を区別するとして扱われます。 しかしながら、ハンドルサービスはASCII文字が無神経な処理ケースであるように方法で実装されるかもしれません。 例えば、Global Handle Registry(GHR)はASCII文字が大文字と小文字を区別しない方法で処理されるところにハンドルサービスを提供します。 これは、どんな命名権威でもASCII文字が大文字と小文字を区別しないと示唆します。
When handles are created under a case-insensitive handle server, their original case should be preserved. To avoid any confusion, the server should avoid creating any handle whose character string matches that of an existing handle, ignoring the case difference. For example, if the handle "X/Y" was already created, the server should refuse any request to create the handle "x/y" or any of its case variations.
ハンドルが大文字と小文字を区別しないハンドルサーバの下で作成されるとき、それらのオリジナルのケースは保存されるべきです。 どんな混乱も避けるために、サーバは、文字列が既存のハンドルのものに合っているどんなハンドルも作成するのを避けるべきです、ケース差を無視して。 例えば、ハンドル「X/Y」が既に作成されるなら、サーバはハンドル「x/y」を作成するというどんな要求かケース変化のいずれも拒否するでしょうに。
Sun, et al. Informational [Page 6] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[6ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
2.1.4. Standard String Type: UTF8-String
2.1.4. 標準のストリングタイプ: UTF8-ストリング
Handles are transmitted as UTF8-Strings under the Handle protocol. Throughout this document, UTF8-String stands for the data type that consists of a 4-byte unsigned integer followed by a character string in UTF-8 encoding. The leading integer specifies the number of octets of the character string.
Handleの下のUTF8-ストリングが議定書を作るのに応じて、ハンドルは送られます。 このドキュメント中では、4バイトの符号のない整数から成るデータ型のためのUTF8-ストリングスタンドはUTF-8コード化における文字列で続きました。 主な整数は文字列の八重奏の数を指定します。
2.2. Common Elements
2.2. 一般的なElements
Each message exchanged under the system protocol consists of four sections (see Fig. 2.2). Some of these sections (e.g., the Message Body) may be empty depending on the protocol operation.
システムプロトコルの下で交換された各メッセージは4つのセクションから成ります(図2.2を参照してください)。 プロトコル操作によって、これらの数人のセクション(例えば、Message Body)が空であるかもしれません。
The Message Envelope must always be present. It has a fixed size of 20 octets. The Message Envelope does not carry any application layer information and is primarily used to help deliver the message. Content in the Message Envelope is not protected by the digital signature in the Message Credential.
Message Envelopeはいつも存在していなければなりません。 それには、20の八重奏の固定サイズがあります。 Message Envelopeは、少しの応用層情報も運ばないで、メッセージを提供するのを助けるのに主として使用されます。 Message Envelopeの内容はMessage Credentialのデジタル署名で保護されません。
The Message Header must always be present as well. It has a fixed size of 24 octets and holds the common data fields of all messages exchanged between client and server. These include the operation code, the response code, and the control options for each protocol operation. Content in the Message Header is protected by the digital signature in the Message Credential.
また、Message Headerはいつも存在していなければなりません。 それには、24の八重奏の固定サイズがあります、そして、すべてのメッセージの一般的なデータ・フィールドがクライアントとサーバこれらの間で交換した船倉はそれぞれのプロトコル操作のための命令コード、応答コード、および規制オプションを含んでいます。 Message Headerの内容はMessage Credentialのデジタル署名で保護されます。
The Message Body contains data specific to each protocol operation. Its format varies according to the operation code and the response code in the Message Header. The Message Body may be empty. Content in the Message Body is protected by the digital signature in the Message Credential.
Message Bodyはそれぞれのプロトコル操作に特定のデータを含んでいます。 Message Headerの命令コードと応答コードによると、形式は異なります。 Message Bodyは空であるかもしれません。 Message Bodyの内容はMessage Credentialのデジタル署名で保護されます。
The Message Credential provides a mechanism for transport security for any message exchanged between the client and server. A non-empty Message Credential may contain the digital signature from the originator of the message or the one-way Message Authentication Code (MAC) based on a pre-established session key. The Message Credential may be used to authenticate the message between the client and server. It can also be used to check data integrity after its transmission.
Message Credentialはクライアントとサーバの間で交換されたどんなメッセージのためにも輸送セキュリティにメカニズムを提供します。非空のMessage Credentialはプレ確立したセッションキーに基づくメッセージか一方向メッセージ立証コード(MAC)の創始者からのデジタル署名を含むかもしれません。 クライアントとサーバの間のメッセージを認証するのにMessage Credentialを使用するかもしれません。また、トランスミッションの後にデータ保全をチェックするのにそれを使用できます。
Sun, et al. Informational [Page 7] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[7ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
.----------------------.
| | ; Message wrapper for proper message
| Message Envelope | ; delivery. Not protected by the
| | ; digital signature in the Message
| | ; Credential.
|----------------------|
| | ; Common data fields for all handle
| Message Header | ; operations.
| |
|----------------------|
| | ; Specific data fields for each
| Message Body | ; request/response.
| |
|----------------------|
| | ; Contains digital signature or
| Message Credential | ; message authentication code (MAC)
| | ; upon Message Header and Message
'----------------------' ; Body.
.----------------------. | | ; 適切なメッセージのためのメッセージラッパー| メッセージ封筒| ; 配送。 保護しません。| | ; Messageのデジタル署名| | ; 資格証明。 |----------------------| | | ; すべてのハンドルのための一般的なデータ・フィールド| メッセージヘッダー| ; 操作。 | | |----------------------| | | ; それぞれのための特定のデータ・フィールド| メッセージ本体| ; 要求/応答。 | | |----------------------| | | ; またはデジタル署名を含んでいる。| メッセージ資格証明書| ; メッセージ確認コード(MAC)| | ; 'メッセージヘッダーとメッセージ'----------------------' ; ボディー。
Fig 2.2: Message format under the Handle protocol
図2.2: Handleプロトコルの下におけるメッセージ・フォーマット
2.2.1. Message Envelope
2.2.1. メッセージ封筒
Each message begins with a Message Envelope under the Handle protocol. If a message has to be truncated before its transmission, each truncated portion must also begin with a Message Envelope.
各メッセージはHandleプロトコルの下におけるMessage Envelopeと共に始まります。 また、メッセージがトランスミッションの前に先端を切られなければならないなら、それぞれの端が欠けている部分はMessage Envelopeと共に始まらなければなりません。
The Message Envelope allows the reassembly of the message at the receiving end. It has a fixed size of 20 octets and consists of seven fields:
Message Envelopeは犠牲者にメッセージの再アセンブリを許容します。 それは、20の八重奏の固定サイズを持って、7つの分野から成ります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| MajorVersion | MinorVersion | MessageFlag |
|---------------------------------------------------------------|
| SessionId |
|---------------------------------------------------------------|
| RequestId |
|---------------------------------------------------------------|
| SequenceNumber |
|---------------------------------------------------------------|
| MessageLength |
'---------------------------------------------------------------'
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 .---------------------------------------------------------------. | MajorVersion| MinorVersion| MessageFlag| |---------------------------------------------------------------| | SessionId| |---------------------------------------------------------------| | RequestId| |---------------------------------------------------------------| | SequenceNumber| |---------------------------------------------------------------| | MessageLength| '---------------------------------------------------------------'
Sun, et al. Informational [Page 8] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[8ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
2.2.1.1. <MajorVersion> and <MinorVersion>
2.2.1.1. <MajorVersion>と<MinorVersion>。
The <MajorVersion> and <MinorVersion> are used to identify the version of the Handle protocol. Each of them is defined as a one- byte unsigned integer. This specification defines the protocol version whose <MajorVersion> is 2 and <MinorVersion> is 1.
<MajorVersion>と<MinorVersion>は、Handleプロトコルのバージョンを特定するのに使用されます。 それぞれのそれらはa1バイト符号のない整数と定義されます。 この仕様は<MajorVersion>が2であるプロトコルバージョンを定義します、そして、<MinorVersion>は1です。
<MajorVersion> and <MinorVersion> are designed to allow future backward compatibility. A difference in <MajorVersion> indicates major variation in the protocol format and the party with the lower <MajorVersion> will have to upgrade its software to ensure precise communication. An increment in <MinorVersion> is made when additional capabilities are added to the protocol without any major change to the message format.
<MajorVersion>と<MinorVersion>は、将来の後方の互換性を許容するように設計されています。 <MajorVersion>の違いは、下側の<MajorVersion>があるプロトコル形式と党の主要な変化が正確なコミュニケーションを確実にするためにソフトウェアをアップグレードさせなければならないのを示します。 追加能力がメッセージ・フォーマットへの少しも大きな変化なしでプロトコルに追加されるとき、<MinorVersion>の増分は作られます。
2.2.1.2. <MessageFlag>
2.2.1.2. <MessageFlag>。
The <MessageFlag> consists of two octets defined as follows:
<MessageFlag>は以下の通り定義された2つの八重奏から成ります:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|CP |EC |TC | Reserved |
'---------------------------------------------------------------'
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .---------------------------------------------------------------. |CP|EC|Tc| 予約されます。| '---------------------------------------------------------------'
Bit 0 is the CP (ComPressed) flag that indicates whether the message (excluding the Message Envelope) is compressed. If the CP bit is set (to 1), the message is compressed. Otherwise, the message is not compressed. The Handle protocol uses the same compression method as used by the FTP protocol[8].
ビット0はメッセージ(Message Envelopeを除いた)が圧縮されるかどうかを示すCP(ComPressed)旗です。 CPビットが設定されるなら(1に)、メッセージは圧縮されます。 さもなければ、メッセージは圧縮されません。 HandleプロトコルはFTPプロトコル[8]で中古の同じ同じくらい圧縮方法を使用します。
Bit 1 is the EC (EnCrypted) flag that indicates whether the message (excluding the Message Envelope) is encrypted. The EC bit should only be set under an established session where a session key is in place. If the EC bit is set (to 1), the message is encrypted using the session key. Otherwise the message is not encrypted.
ビット1はメッセージ(Message Envelopeを除いた)が暗号化されているかどうかを示すEC(EnCrypted)旗です。 ECビットはセッションキーが適所にある確立したセッションの下に設定されるだけであるべきです。 ECビットが設定されるなら(1に)、メッセージは、セッションキーを使用することで暗号化されています。 さもなければ、メッセージは暗号化されていません。
Bit 2 is the TC (TrunCated) flag that indicates whether this is a truncated message. Message truncation happens most often when transmitting a large message over the UDP protocol. Details of message truncation (or fragmentation) will be discussed in section 2.3.
ビット2はこれが端が欠けているメッセージであるかどうかを示すTC(TrunCated)旗です。 たいていUDPプロトコルの上に大きいメッセージを送るとき、メッセージトランケーションは起こります。 セクション2.3でメッセージトランケーション(または、断片化)の詳細について議論するでしょう。
Bits 3 to 15 are currently reserved and must be set to zero.
ビット3〜15を現在、予約されて、ゼロに設定しなければなりません。
Sun, et al. Informational [Page 9] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[9ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
2.2.1.3. <SessionId>
2.2.1.3. <SessionId>。
The <SessionId> is a four-byte unsigned integer that identifies a communication session between the client and server.
<SessionId>はクライアントとサーバとのコミュニケーションセッションを特定する4バイトの符号のない整数です。
Session and its <SessionId> are assigned by a server, either upon an explicit request from a client or when multiple message exchanges are expected to fulfill the client's request. For example, the server will assign a unique <SessionId> in its response if it has to authenticate the client. A client may explicitly ask the server to set up a session as a virtually private communication channel like SSL [4]. Requests from clients without an established session must have their <SessionId> set to zero. The server must assign a unique non-zero <SessionId> for each new session. It is also responsible for terminating those sessions that are not in use after some period of time.
セッションとその<SessionId>はサーバによって割り当てられます、クライアントからの明白な要求かそれともいつ複数の交換処理がクライアントの要求を実現させると予想されるかに関して。 例えば、クライアントを認証しなければならないと、サーバは応答でユニークな<SessionId>を割り当てるでしょう。 クライアントは、SSL[4]のような実際には個人的な通信チャネルとしてセッションをセットアップするように明らかにサーバに頼むかもしれません。 確立したセッションのないクライアントからの要求で、彼らの<SessionId>をゼロに用意ができさせなければなりません。 サーバはそれぞれの新しいセッションのためにユニークな非ゼロ<SessionId>を割り当てなければなりません。 また、それもそれらのいつかの期間の後に使用中でないセッションを終えるのに責任があります。
Both clients and servers must maintain the same <SessionId> for messages exchanged under an established session. A message whose <SessionId> is zero indicates that no session has been established.
クライアントとサーバの両方が確立したセッションで交換されたメッセージのために同じ<SessionId>を維持しなければなりません。 <SessionId>がゼロであるメッセージは、セッションが全く確立されていないのを示します。
The session and its state information may be shared among multiple handle operations. They may also be shared over multiple TCP connections as well. Once a session is established, both client and server must maintain their state information according to the <SessionId>. The state information may include the stage of the conversation, the other party's authentication information, and the session key that was established for message encryption or authentication. Details of these are discussed in section 3.8.
セッションとその州の情報は複数のハンドル操作の中で共有されるかもしれません。 また、それらはまた、複数のTCP接続の上で共有されるかもしれません。 セッションがいったん確立されると、<SessionId>によると、クライアントとサーバの両方がそれらの州の情報を保守しなければなりません。 州の情報は会話のステージ、相手の認証情報、およびメッセージ暗号化か認証のために確立されたセッションキーを含むかもしれません。 セクション3.8でこれらの詳細について議論します。
2.2.1.4. <RequestId>
2.2.1.4. <RequestId>。
Each request from a client is identified by a <RequestId>, a 4-byte unsigned integer set by the client. Each <RequestId> must be unique from all other outstanding requests from the same client. The <RequestId> allows the client to keep track of its requests, and any response from the server must include the correct <RequestId>.
クライアントからの各要求は<RequestId>によって特定されて、4バイトの符号のない整数はクライアントでセットしました。 それぞれの<RequestId>は同じクライアントからの他のすべての傑出している要求によってユニークであるに違いありません。 <RequestId>はクライアントに要求に動向をおさえさせます、そして、サーバからのどんな応答も正しい<RequestId>を含まなければなりません。
2.2.1.5. <SequenceNumber>
2.2.1.5. <SequenceNumber>。
Messages under the Handle protocol may be truncated during their transmission (e.g., under UDP). The <SequenceNumber> is a 4-byte unsigned integer used as a counter to keep track of each truncated portion of the original message. The message recipient can reassemble the original message based on the <SequenceNumber>. The <SequenceNumber> must start with 0 for each message. Each truncated message must set its TC flag in the Message Envelope. Messages that are not truncated must set their <SequenceNumber> to zero.
Handleプロトコルの下におけるメッセージは彼らのトランスミッション(例えば、UDPの下の)の間、先端を切られるかもしれません。 <SequenceNumber>はオリジナルのメッセージのそれぞれの端が欠けている部分の動向をおさえるのにカウンタとして使用される4バイトの符号のない整数です。 メッセージ受取人は<SequenceNumber>に基づくオリジナルのメッセージを組み立て直すことができます。 <SequenceNumber>は各メッセージあたり0から始まらなければなりません。 それぞれの端が欠けているメッセージはTC旗をMessage Envelopeにはめ込まなければなりません。 端が欠けていないメッセージはそれらの<SequenceNumber>をゼロに設定しなければなりません。
Sun, et al. Informational [Page 10] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 10] RFC 3652 Handle System Protocol (v2.1) November 2003
2.2.1.6. <MessageLen>
2.2.1.6. <MessageLen>
A 4-byte unsigned integer that specifies the total number of octets of any message, excluding those in the Message Envelope. The length of any single message exchanged under the Handle protocol is limited by the range of a 4-byte unsigned integer. Longer data can be transmitted as multiple messages with a common <RequestId>.
A 4-byte unsigned integer that specifies the total number of octets of any message, excluding those in the Message Envelope. The length of any single message exchanged under the Handle protocol is limited by the range of a 4-byte unsigned integer. Longer data can be transmitted as multiple messages with a common <RequestId>.
2.2.2. Message Header
2.2.2. Message Header
The Message Header contains the common data elements among any protocol operation. It has a fixed size of 24 octets and consists of eight fields.
The Message Header contains the common data elements among any protocol operation. It has a fixed size of 24 octets and consists of eight fields.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| OpCode |
|---------------------------------------------------------------|
| ResponseCode |
|---------------------------------------------------------------|
| OpFlag |
|---------------------------------------------------------------|
| SiteInfoSerialNumber | RecursionCount| |
|---------------------------------------------------------------|
| ExpirationTime |
|---------------------------------------------------------------|
| BodyLength |
'---------------------------------------------------------------'
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 .---------------------------------------------------------------. | OpCode | |---------------------------------------------------------------| | ResponseCode | |---------------------------------------------------------------| | OpFlag | |---------------------------------------------------------------| | SiteInfoSerialNumber | RecursionCount| | |---------------------------------------------------------------| | ExpirationTime | |---------------------------------------------------------------| | BodyLength | '---------------------------------------------------------------'
Every message that is not truncated must have a Message Header. If a message has to be truncated for its transmission, the Message Header must appear in the first truncated portion of the message.
Every message that is not truncated must have a Message Header. If a message has to be truncated for its transmission, the Message Header must appear in the first truncated portion of the message.
This is different from the Message Envelope, which appears in each truncated portion of the message.
This is different from the Message Envelope, which appears in each truncated portion of the message.
2.2.2.1. <OpCode>
2.2.2.1. <OpCode>
The <OpCode> stands for operation code, which is a four-byte unsigned integer that specifies the intended operation. The following table lists the <OpCode>s that MUST be supported by all implementations in order to conform to the base protocol specification. Each operation code is given a symbolic name that is used throughout this document for easy reference.
The <OpCode> stands for operation code, which is a four-byte unsigned integer that specifies the intended operation. The following table lists the <OpCode>s that MUST be supported by all implementations in order to conform to the base protocol specification. Each operation code is given a symbolic name that is used throughout this document for easy reference.
Sun, et al. Informational [Page 11] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 11] RFC 3652 Handle System Protocol (v2.1) November 2003
Op_Code Symbolic Name Remark
--------- ------------- ------
Op_Code Symbolic Name Remark --------- ------------- ------
0 OC_RESERVED Reserved
1 OC_RESOLUTION Handle query
2 OC_GET_SITEINFO Get HS_SITE values
0 OC_RESERVED Reserved 1 OC_RESOLUTION Handle query 2 OC_GET_SITEINFO Get HS_SITE values
100 OC_CREATE_HANDLE Create new handle
101 OC_DELETE_HANDLE Delete existing handle
102 OC_ADD_VALUE Add handle value(s)
103 OC_REMOVE_VALUE Remove handle value(s)
104 OC_MODIFY_VALUE Modify handle value(s)
105 OC_LIST_HANDLE List handles
106 OC_LIST_NA List sub-naming authorities
100 OC_CREATE_HANDLE Create new handle 101 OC_DELETE_HANDLE Delete existing handle 102 OC_ADD_VALUE Add handle value(s) 103 OC_REMOVE_VALUE Remove handle value(s) 104 OC_MODIFY_VALUE Modify handle value(s) 105 OC_LIST_HANDLE List handles 106 OC_LIST_NA List sub-naming authorities
200 OC_CHALLENGE_RESPONSE Response to challenge
201 OC_VERIFY_RESPONSE Verify challenge response
200 OC_CHALLENGE_RESPONSE Response to challenge 201 OC_VERIFY_RESPONSE Verify challenge response
300
: { Reserved for handle server administration }
399
300 : { Reserved for handle server administration } 399
400 OC_SESSION_SETUP Session setup request
401 OC_SESSION_TERMINATE Session termination request
402 OC_SESSION_EXCHANGEKEY Session key exchange
400 OC_SESSION_SETUP Session setup request 401 OC_SESSION_TERMINATE Session termination request 402 OC_SESSION_EXCHANGEKEY Session key exchange
A detailed description of each of these <OpCode>s can be found in section 3 of this document. In general, clients use the <OpCode> to tell the server what kind of handle operation they want to accomplish. Response from the server must maintain the same <OpCode> as the original request and use the <ResponseCode> to indicate the result.
A detailed description of each of these <OpCode>s can be found in section 3 of this document. In general, clients use the <OpCode> to tell the server what kind of handle operation they want to accomplish. Response from the server must maintain the same <OpCode> as the original request and use the <ResponseCode> to indicate the result.
2.2.2.2. <ResponseCode>
2.2.2.2. <ResponseCode>
The <ResponseCode> is a 4-byte unsigned integer that is given by a server to indicate the result of any service request. The list of <ResponseCode>s used in the Handle protocol is defined in the following table. Each response code is given a symbolic name that is used throughout this document for easy reference.
The <ResponseCode> is a 4-byte unsigned integer that is given by a server to indicate the result of any service request. The list of <ResponseCode>s used in the Handle protocol is defined in the following table. Each response code is given a symbolic name that is used throughout this document for easy reference.
Sun, et al. Informational [Page 12] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 12] RFC 3652 Handle System Protocol (v2.1) November 2003
Res. Code Symbolic Name Remark
--------- ------------- ------
Res. Code Symbolic Name Remark --------- ------------- ------
0 RC_RESERVED Reserved for request
1 RC_SUCCESS Success response
2 RC_ERROR General error
3 RC_SERVER_BUSY Server too busy to respond
4 RC_PROTOCOL_ERROR Corrupted or
unrecognizable message
5 RC_OPERATION_DENIED Unsupported operation
6 RC_RECUR_LIMIT_EXCEEDED Too many recursions for
the request
0 RC_RESERVED Reserved for request 1 RC_SUCCESS Success response 2 RC_ERROR General error 3 RC_SERVER_BUSY Server too busy to respond 4 RC_PROTOCOL_ERROR Corrupted or unrecognizable message 5 RC_OPERATION_DENIED Unsupported operation 6 RC_RECUR_LIMIT_EXCEEDED Too many recursions for the request
100 RC_HANDLE_NOT_FOUND Handle not found
101 RC_HANDLE_ALREADY_EXIST Handle already exists
102 RC_INVALID_HANDLE Encoding (or syntax) error
100 RC_HANDLE_NOT_FOUND Handle not found 101 RC_HANDLE_ALREADY_EXIST Handle already exists 102 RC_INVALID_HANDLE Encoding (or syntax) error
200 RC_VALUE_NOT_FOUND Value not found
201 RC_VALUE_ALREADY_EXIST Value already exists
202 RC_VALUE_INVALID Invalid handle value
200 RC_VALUE_NOT_FOUND Value not found 201 RC_VALUE_ALREADY_EXIST Value already exists 202 RC_VALUE_INVALID Invalid handle value
300 RC_EXPIRED_SITE_INFO SITE_INFO out of date
301 RC_SERVER_NOT_RESP Server not responsible
302 RC_SERVICE_REFERRAL Server referral
303 RC_NA_DELEGATE Naming authority delegation
takes place.
300 RC_EXPIRED_SITE_INFO SITE_INFO out of date 301 RC_SERVER_NOT_RESP Server not responsible 302 RC_SERVICE_REFERRAL Server referral 303 RC_NA_DELEGATE Naming authority delegation takes place.
400 RC_NOT_AUTHORIZED Not authorized/permitted
401 RC_ACCESS_DENIED No access to data
402 RC_AUTHEN_NEEDED Authentication required
403 RC_AUTHEN_FAILED Failed to authenticate
404 RC_INVALID_CREDENTIAL Invalid credential
405 RC_AUTHEN_TIMEOUT Authentication timed out
406 RC_UNABLE_TO_AUTHEN Unable to authenticate
400 RC_NOT_AUTHORIZED Not authorized/permitted 401 RC_ACCESS_DENIED No access to data 402 RC_AUTHEN_NEEDED Authentication required 403 RC_AUTHEN_FAILED Failed to authenticate 404 RC_INVALID_CREDENTIAL Invalid credential 405 RC_AUTHEN_TIMEOUT Authentication timed out 406 RC_UNABLE_TO_AUTHEN Unable to authenticate
500 RC_SESSION_TIMEOUT Session expired
501 RC_SESSION_FAILED Unable to establish session
502 RC_NO_SESSION_KEY No session yet available
503 RC_SESSION_NO_SUPPORT Session not supported
504 RC_SESSION_KEY_INVALID Invalid session key
500 RC_SESSION_TIMEOUT Session expired 501 RC_SESSION_FAILED Unable to establish session 502 RC_NO_SESSION_KEY No session yet available 503 RC_SESSION_NO_SUPPORT Session not supported 504 RC_SESSION_KEY_INVALID Invalid session key
900 RC_TRYING Request under processing
901 RC_FORWARDED Request forwarded to
another server
902 RC_QUEUED Request queued for later
processing
900 RC_TRYING Request under processing 901 RC_FORWARDED Request forwarded to another server 902 RC_QUEUED Request queued for later processing
Sun, et al. Informational [Page 13] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 13] RFC 3652 Handle System Protocol (v2.1) November 2003
Response codes under 10000 are reserved for system use. Any message with a response code under 10000 but not listed above should be treated as an unknown error. Response codes above 10000 are user defined and can be used for application specific purposes.
Response codes under 10000 are reserved for system use. Any message with a response code under 10000 but not listed above should be treated as an unknown error. Response codes above 10000 are user defined and can be used for application specific purposes.
Detailed descriptions of these <ResponseCode>s can be found in section 3 of this document. In general, any request from a client must have its <ResponseCode> set to 0. The response message from the server must have a non-zero <ResponseCode> to indicate the result. For example, a response message from a server with <ResponseCode> set to RC_SUCCESS indicates that the server has successfully fulfilled the client's request.
Detailed descriptions of these <ResponseCode>s can be found in section 3 of this document. In general, any request from a client must have its <ResponseCode> set to 0. The response message from the server must have a non-zero <ResponseCode> to indicate the result. For example, a response message from a server with <ResponseCode> set to RC_SUCCESS indicates that the server has successfully fulfilled the client's request.
2.2.2.3. <OpFlag>
2.2.2.3. <OpFlag>
The <OpFlag> is a 32-bit bit-mask that defines various control options for protocol operation. The following figure shows the location of each option flag in the <OpFlag> field.
The <OpFlag> is a 32-bit bit-mask that defines various control options for protocol operation. The following figure shows the location of each option flag in the <OpFlag> field.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
.---------------------------------------------------------------.
|AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved |
|---------------------------------------------------------------|
| Reserved |
'---------------------------------------------------------------'
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .---------------------------------------------------------------. |AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved | |---------------------------------------------------------------| | Reserved | '---------------------------------------------------------------'
AT - AuThoritative bit. A request with the AT bit set (to 1)
indicates that the request should be directed to the
primary service site (instead of any mirroring sites). A
response message with the AT bit set (to 1) indicates
that the message is returned from a primary server
(within the primary service site).
AT - AuThoritative bit. A request with the AT bit set (to 1) indicates that the request should be directed to the primary service site (instead of any mirroring sites). A response message with the AT bit set (to 1) indicates that the message is returned from a primary server (within the primary service site).
CT - CerTified bit. A request with the CT bit set (to 1) asks
the server to sign its response with its digital
signature. A response with the CT bit set (to 1)
indicates that the message is signed. The server must
sign its response if the request has its CT bit set (to
1). If the server fails to provide a valid signature in
its response, the client should discard the response and
treat the request as failed.
CT - CerTified bit. A request with the CT bit set (to 1) asks the server to sign its response with its digital signature. A response with the CT bit set (to 1) indicates that the message is signed. The server must sign its response if the request has its CT bit set (to 1). If the server fails to provide a valid signature in its response, the client should discard the response and treat the request as failed.
ENC - ENCryption bit. A request with the ENC bit set (to 1)
requires the server to encrypt its response using the
pre-established session key.
ENC - ENCryption bit. A request with the ENC bit set (to 1) requires the server to encrypt its response using the pre-established session key.
Sun, et al. Informational [Page 14] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 14] RFC 3652 Handle System Protocol (v2.1) November 2003
REC - RECursive bit. A request with the REC bit set (to 1)
asks the server to forward the query on behalf of the
client if the request has to be processed by another
handle server. The server may honor the request by
forwarding the request to the appropriate handle server
and passing on any result back to the client. The server
may also deny any such request by sending a response
with <ResponseCode> set to RC_SERVER_NOT_RESP.
REC - RECursive bit. A request with the REC bit set (to 1) asks the server to forward the query on behalf of the client if the request has to be processed by another handle server. The server may honor the request by forwarding the request to the appropriate handle server and passing on any result back to the client. The server may also deny any such request by sending a response with <ResponseCode> set to RC_SERVER_NOT_RESP.
CA - Cache Authentication. A request with the CA bit set (to
1) asks the caching server (if any) to authenticate any
server response (e.g., verifying the server's signature)
on behalf of the client. A response with the CA bit set
(to 1) indicates that the response has been
authenticated by the caching server.
CA - Cache Authentication. A request with the CA bit set (to 1) asks the caching server (if any) to authenticate any server response (e.g., verifying the server's signature) on behalf of the client. A response with the CA bit set (to 1) indicates that the response has been authenticated by the caching server.
CN - ContiNuous bit. A message with the CN bit set (to 1)
tells the message recipient that more messages that are
part of the same request (or response) will follow. This
happens if a request (or response) has data that is too
large to fit into any single message and has to be
fragmented into multiple messages.
CN - ContiNuous bit. A message with the CN bit set (to 1) tells the message recipient that more messages that are part of the same request (or response) will follow. This happens if a request (or response) has data that is too large to fit into any single message and has to be fragmented into multiple messages.
KC - Keep Connection bit. A message with the KC bit set
requires the message recipient to keep the TCP
connection open (after the response is sent back). This
allows the same TCP connection to be used for multiple
handle operations.
KC - Keep Connection bit. A message with the KC bit set requires the message recipient to keep the TCP connection open (after the response is sent back). This allows the same TCP connection to be used for multiple handle operations.
PO - Public Only bit. Used by query operations only. A query
request with the PO bit set (to 1) indicates that the
client is only asking for handle values that have the
PUB_READ permission. A request with PO bit set to zero
asks for all the handle values regardless of their read
permission. If any of the handle values require
ADMIN_READ permission, the server must authenticate the
client as the handle administrator.
PO - Public Only bit. Used by query operations only. A query request with the PO bit set (to 1) indicates that the client is only asking for handle values that have the PUB_READ permission. A request with PO bit set to zero asks for all the handle values regardless of their read permission. If any of the handle values require ADMIN_READ permission, the server must authenticate the client as the handle administrator.
RD - Request-Digest bit. A request with the RD bit set (to 1)
asks the server to include in its response the message
digest of the request. A response message with the RD
bit set (to 1) indicates that the first field in the
Message Body contains the message digest of the original
request. The message digest can be used to check the
integrity of the server response. Details of these are
discussed later in this document.
RD - Request-Digest bit. A request with the RD bit set (to 1) asks the server to include in its response the message digest of the request. A response message with the RD bit set (to 1) indicates that the first field in the Message Body contains the message digest of the original request. The message digest can be used to check the integrity of the server response. Details of these are discussed later in this document.
Sun, et al. Informational [Page 15] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 15] RFC 3652 Handle System Protocol (v2.1) November 2003
All other bits in the <OpFlag> field are reserved and must be set to zero.
All other bits in the <OpFlag> field are reserved and must be set to zero.
In general, servers must honor the <OpFlag> specified in the request. If a requested option cannot be met, the server should return an error message with the proper <ResponseCode> as defined in the previous section.
In general, servers must honor the <OpFlag> specified in the request. If a requested option cannot be met, the server should return an error message with the proper <ResponseCode> as defined in the previous section.
2.2.2.4. <SiteInfoSerialNumber>
2.2.2.4. <SiteInfoSerialNumber>
The <SiteInfoSerialNumber> is a two-byte unsigned integer. The <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of the HS_SITE value used by the client (to access the server). Servers can check the <SiteInfoSerialNumber> in the request to find out if the client has up-to-date service information.
The <SiteInfoSerialNumber> is a two-byte unsigned integer. The <SiteInfoSerialNumber> in a request refers to the <SerialNumber> of the HS_SITE value used by the client (to access the server). Servers can check the <SiteInfoSerialNumber> in the request to find out if the client has up-to-date service information.
When possible, the server should fulfill a client's request even if the service information used by the client is out-of-date. However, the response message should specify the latest version of service information in the <SiteInforSerialNumber> field. Clients with out- of-date service information can update the service information from the Global Handle Registry. If the server cannot fulfill a client's request due to expired service information, it should reject the request and return an error message with <ResponseCode> set to RC_EXPIRED_SITE_INFO.
When possible, the server should fulfill a client's request even if the service information used by the client is out-of-date. However, the response message should specify the latest version of service information in the <SiteInforSerialNumber> field. Clients with out- of-date service information can update the service information from the Global Handle Registry. If the server cannot fulfill a client's request due to expired service information, it should reject the request and return an error message with <ResponseCode> set to RC_EXPIRED_SITE_INFO.
2.2.2.5. <RecursionCount>
2.2.2.5. <RecursionCount>
The <RecursionCount> is a one-byte unsigned integer that specifies the number of service recursions. Service recursion happens if the server has to forward the client's request to another server. Any request directly from the client must have its <RecursionCount> set to 0. If the server has to send a recursive request on behalf of the client, it must increment the <RecursionCount> by 1. Any response from the server must maintain the same <RecursionCount> as the one in the request. To prevent an infinite loop of service recursion, the server should be configurable to stop sending a recursive request when the <RecursionCount> reaches a certain value.
The <RecursionCount> is a one-byte unsigned integer that specifies the number of service recursions. Service recursion happens if the server has to forward the client's request to another server. Any request directly from the client must have its <RecursionCount> set to 0. If the server has to send a recursive request on behalf of the client, it must increment the <RecursionCount> by 1. Any response from the server must maintain the same <RecursionCount> as the one in the request. To prevent an infinite loop of service recursion, the server should be configurable to stop sending a recursive request when the <RecursionCount> reaches a certain value.
2.2.2.6. <ExpirationTime>
2.2.2.6. <ExpirationTime>
The <ExpirationTime> is a 4-byte unsigned integer that specifies the time when the message should be considered expired, relative to January 1st, 1970 GMT, in seconds. It is set to zero if no expiration is expected.
The <ExpirationTime> is a 4-byte unsigned integer that specifies the time when the message should be considered expired, relative to January 1st, 1970 GMT, in seconds. It is set to zero if no expiration is expected.
Sun, et al. Informational [Page 16] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 16] RFC 3652 Handle System Protocol (v2.1) November 2003
2.2.2.7. <BodyLength>
2.2.2.7. <BodyLength>
The <BodyLength> is a 4-byte unsigned integer that specifies the number of octets in the Message Body. The <BodyLength> does not count the octets in the Message Header or those in the Message Credential.
The <BodyLength> is a 4-byte unsigned integer that specifies the number of octets in the Message Body. The <BodyLength> does not count the octets in the Message Header or those in the Message Credential.
2.2.3. Message Body
2.2.3. Message Body
The Message Body always follows the Message Header. The number of octets in the Message Body can be determined from the <BodyLength> in the Message Header. The Message Body may be empty. The exact format of the Message Body depends on the <OpCode> and the <ResponseCode> in the Message Header. Details of the Message Body under each <OpCode> and <ResponseCode> are described in section 3 of this document.
The Message Body always follows the Message Header. The number of octets in the Message Body can be determined from the <BodyLength> in the Message Header. The Message Body may be empty. The exact format of the Message Body depends on the <OpCode> and the <ResponseCode> in the Message Header. Details of the Message Body under each <OpCode> and <ResponseCode> are described in section 3 of this document.
For any response message, if the Message Header has its RD bit (in <OpFlag>) set to 1, the Message Body must begin with the message digest of the original request. The message digest is defined as follows:
For any response message, if the Message Header has its RD bit (in <OpFlag>) set to 1, the Message Body must begin with the message digest of the original request. The message digest is defined as follows:
<RequestDigest> ::= <DigestAlgorithmIdentifier>
<MessageDigest>
<RequestDigest> ::= <DigestAlgorithmIdentifier> <MessageDigest>
where
where
<DigestAlgorithmIdentifier>
An octet that identifies the algorithm used to generate the
message digest. If the octet is set to 1, the digest is
generated using the MD5 [9] algorithm. If the octet is set
to 2, SHA-1 [10] algorithm is used.
<DigestAlgorithmIdentifier> An octet that identifies the algorithm used to generate the message digest. If the octet is set to 1, the digest is generated using the MD5 [9] algorithm. If the octet is set to 2, SHA-1 [10] algorithm is used.
<MessageDigest>
The message digest itself. It is calculated upon the
Message Header and the Message Body of the original request.
The length of the field is fixed according to the digest
algorithm. For MD5 algorithm, the length is 16 octets. For
SHA-1, the length is 20 octets.
<MessageDigest> The message digest itself. It is calculated upon the Message Header and the Message Body of the original request. The length of the field is fixed according to the digest algorithm. For MD5 algorithm, the length is 16 octets. For SHA-1, the length is 20 octets.
The Message Body may be truncated into multiple portions during its transmission (e.g., over UDP). Recipients of such a message may reassemble the Message Body from each portion based on the <SequenceNumber> in the Message Envelope.
The Message Body may be truncated into multiple portions during its transmission (e.g., over UDP). Recipients of such a message may reassemble the Message Body from each portion based on the <SequenceNumber> in the Message Envelope.
Sun, et al. Informational [Page 17] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 17] RFC 3652 Handle System Protocol (v2.1) November 2003
2.2.4. Message Credential
2.2.4. Message Credential
The Message Credential is primarily used to carry any digital signatures signed by the message issuer. It may also carry the Message Authentication Code (MAC) if a session key has been established. The Message Credential is used to protect contents in the Message Header and the Message Body from being tampered with during transmission. The format of the Message Credential is designed to be semantically compatible with PKCS#7 [5]. Each Message Credential consists of the following fields:
The Message Credential is primarily used to carry any digital signatures signed by the message issuer. It may also carry the Message Authentication Code (MAC) if a session key has been established. The Message Credential is used to protect contents in the Message Header and the Message Body from being tampered with during transmission. The format of the Message Credential is designed to be semantically compatible with PKCS#7 [5]. Each Message Credential consists of the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
.---------------------------------------------------------------.
| CredentialLength |
|---------------------------------------------------------------|
| Version | Reserved | Options |
|---------------------------------------------------------------|
|
| Signer: <Handle, Index>
|
|---------------------------------------------------------------|
| Type (UTF8-String) |
|---------------------------------------------------------------|
|
| SignedInfo: <Length> : 4-byte unsigned integer
| DigestAlgorithm: <UTF8-String>
| SignedData: <Length, Signature>
|
'---------------------------------------------------------------'
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 .---------------------------------------------------------------. | CredentialLength | |---------------------------------------------------------------| | Version | Reserved | Options | |---------------------------------------------------------------| | | Signer: <Handle, Index> | |---------------------------------------------------------------| | Type (UTF8-String) | |---------------------------------------------------------------| | | SignedInfo: <Length> : 4-byte unsigned integer | DigestAlgorithm: <UTF8-String> | SignedData: <Length, Signature> | '---------------------------------------------------------------'
where
where
<CredentialLength>
A 4-byte unsigned integer that specifies the number of octets in
the Message Credential. It must be set to zero if the message has
no Message Credential.
<CredentialLength> A 4-byte unsigned integer that specifies the number of octets in the Message Credential. It must be set to zero if the message has no Message Credential.
<Version>
An octet that identifies the version number of the Message
Credential. The version number specified in this document is
zero.
<Version> An octet that identifies the version number of the Message Credential. The version number specified in this document is zero.
<Reserved>
An octet that must be set to zero.
<Reserved> An octet that must be set to zero.
<Options>
Two octets reserved for various cryptography options.
<Options> Two octets reserved for various cryptography options.
Sun, et al. Informational [Page 18] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 18] RFC 3652 Handle System Protocol (v2.1) November 2003
<Signer> ::= <HANDLE>
<INDEX>
A reference to a handle value in terms of the <HANDLE> and the
<INDEX> of the handle value. The handle value may contain the
public key, or the X.509 certificate, that can be used to
validate the digital signature.
<Signer> ::= <HANDLE> <INDEX> A reference to a handle value in terms of the <HANDLE> and the <INDEX> of the handle value. The handle value may contain the public key, or the X.509 certificate, that can be used to validate the digital signature.
<Type>
A UTF8-String that indicates the type of content in the
<SignedInfo> field (described below). It may contain HS_DIGEST if
<SignedInfo> contains the message digest, or HS_MAC if
<SignedInfo> contains the Message Authentication Code (MAC). The
<Type> field will specify the signature algorithm identifier if
<SignedInfo> contains a digital signature. For example, with the
<Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will
contain the digital signature generated using the RSA-PSS
algorithm [16]. If the <Type> field is set to HS_SIGNED, the
<SignedInfo> field will contain the digital signature generated
from a DSA public key pair.
<Type> A UTF8-String that indicates the type of content in the <SignedInfo> field (described below). It may contain HS_DIGEST if <SignedInfo> contains the message digest, or HS_MAC if <SignedInfo> contains the Message Authentication Code (MAC). The <Type> field will specify the signature algorithm identifier if <SignedInfo> contains a digital signature. For example, with the <Type> field set to HS_SIGNED_PSS, the <SignedInfo> field will contain the digital signature generated using the RSA-PSS algorithm [16]. If the <Type> field is set to HS_SIGNED, the <SignedInfo> field will contain the digital signature generated from a DSA public key pair.
<SignedInfo> ::= <Length>
<DigestAlgorithm>
<SignedData>
where
<SignedInfo> ::= <Length> <DigestAlgorithm> <SignedData> where
<Length>
A 4-byte unsigned integer that specifies the number of
octets in the <SignedInfo> field.
<Length> A 4-byte unsigned integer that specifies the number of octets in the <SignedInfo> field.
<DigestAlgorithm>
A UTF8-String that refers to the digest algorithm used to
generate the digital signature. For example, the value
"SHA-1" indicates that the SHA-1 algorithm is used to
generate the message digest for the signature.
<DigestAlgorithm> A UTF8-String that refers to the digest algorithm used to generate the digital signature. For example, the value "SHA-1" indicates that the SHA-1 algorithm is used to generate the message digest for the signature.
<SignedData> ::= <LENGTH>
<SIGNATURE>
where
<SignedData> ::= <LENGTH> <SIGNATURE> where
<LENGTH>
A 4-byte unsigned integer that specifies the number of
octets in the <SIGNATURE>.
<LENGTH> A 4-byte unsigned integer that specifies the number of octets in the <SIGNATURE>.
<SIGNATURE>
Contains the digital signature or the MAC over the
Message Header and Message Body. The syntax and
semantics of the signature depend on the <Type> field
<SIGNATURE> Contains the digital signature or the MAC over the Message Header and Message Body. The syntax and semantics of the signature depend on the <Type> field
Sun, et al. Informational [Page 19] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 19] RFC 3652 Handle System Protocol (v2.1) November 2003
and the public key referenced in the <Signer> field.
For example, if the <Type> field is "HS_SIGNED" and
the public key referred to by the <Signer> field is
a DSA [6] public key, the signature will be the
ASN.1 octet string representation of the parameter R
and S as described in [7]. If the <Signer> field
refers to a handle value that contains a X.509
certificate, the signature should be encoded according
to RFC 3279 and RFC 3280 [14, 15].
and the public key referenced in the <Signer> field. For example, if the <Type> field is "HS_SIGNED" and the public key referred to by the <Signer> field is a DSA [6] public key, the signature will be the ASN.1 octet string representation of the parameter R and S as described in [7]. If the <Signer> field refers to a handle value that contains a X.509 certificate, the signature should be encoded according to RFC 3279 and RFC 3280 [14, 15].
The Message Credential may contain the message authentication code (MAC) generated using a pre-established session key. In this case, the <Signer> field must set its <HANDLE> to a zero-length UTF8-String and its <INDEX> to the <SessionId> specified in the Message Envelope. The <Signature> field must contain the MAC in its <SIGNATURE> field. The MAC is the result of the one-way hash over the concatenation of the session key, the <Message Header>, the <MessageBody>, and the session key again.
The Message Credential may contain the message authentication code (MAC) generated using a pre-established session key. In this case, the <Signer> field must set its <HANDLE> to a zero-length UTF8-String and its <INDEX> to the <SessionId> specified in the Message Envelope. The <Signature> field must contain the MAC in its <SIGNATURE> field. The MAC is the result of the one-way hash over the concatenation of the session key, the <Message Header>, the <MessageBody>, and the session key again.
The Message Credential in a response message may contain the digital signature signed by the server. The server's public key can be found in the service information used by the client to send the request to the server. In this case, the client should ignore any reference in the <Signer> field and use the public key in the service information to verify the signature.
The Message Credential in a response message may contain the digital signature signed by the server. The server's public key can be found in the service information used by the client to send the request to the server. In this case, the client should ignore any reference in the <Signer> field and use the public key in the service information to verify the signature.
The Message Credential can also be used for non-repudiation purposes. This happens if the Message Credential contains a server's digital signature. The signature may be used as evidence to demonstrate that the server has rendered its service in response to a client's request.
The Message Credential can also be used for non-repudiation purposes. This happens if the Message Credential contains a server's digital signature. The signature may be used as evidence to demonstrate that the server has rendered its service in response to a client's request.
The Message Credential provides a mechanism for safe transmission of any message between the client and server. Any message whose Message Header and Message Body complies with its Message Credential suggests that the message indeed comes from its originator and assures that the message has not been tampered with during its transmission.
The Message Credential provides a mechanism for safe transmission of any message between the client and server. Any message whose Message Header and Message Body complies with its Message Credential suggests that the message indeed comes from its originator and assures that the message has not been tampered with during its transmission.
2.3. Message Transmission
2.3. Message Transmission
A large message may be truncated into multiple packets during its transmission. For example, to fit the size limit of a UDP packet, the message issuer must truncate any large message into multiple UDP packets before its transmission. The message recipient must reassemble the message from these truncated packets before further processing. Message truncation must be carried out over the entire
大きいメッセージはトランスミッションの間、複数のパケットに先端を切られるかもしれません。 例えば、UDPパケットのサイズ限界に合うように、メッセージ発行人はトランスミッションの前に複数のUDPパケットにどんな大きいメッセージにも先端を切らせなければなりません。 メッセージ受取人はさらに処理する前に、これらの端が欠けているパケットからのメッセージを組み立て直さなければなりません。 全体の上にメッセージトランケーションを行わなければなりません。
Sun, et al. Informational [Page 20] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[20ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
message except the Message Envelope. A new Message Envelope has to be inserted in front of each truncated packet before its transmission. For example, a large message that consists of
Message Envelope以外のメッセージ。 新しいMessage Envelopeはトランスミッションの前にそれぞれの端が欠けているパケットの正面で挿入されなければなりません。 例えば、それが成る大きいメッセージ
.--------------------------------------------------------.
| Message Envelope | Message Header, Body, Credential |
'--------------------------------------------------------'
.--------------------------------------------------------. | メッセージ封筒| メッセージヘッダー、ボディー、資格証明書| '--------------------------------------------------------'
may be truncated into:
以下に先端を切られるかもしれません。
.--------------------------------------------.
| Message Envelope 1 | Truncated_Packet 1 |
'--------------------------------------------'
.--------------------------------------------.
| Message Envelope 2 | Truncated_Packet 2 |
'--------------------------------------------'
.--------------------------------------------. | メッセージ封筒1| 端が欠けている_パケット1| '--------------------------------------------' .--------------------------------------------. | メッセージ封筒2| 端が欠けている_パケット2| '--------------------------------------------'
......
......
.--------------------------------------------.
| Message Envelope N | Truncated Packet N |
'--------------------------------------------'
.--------------------------------------------. | メッセージ封筒N| 端が欠けているパケットN| '--------------------------------------------'
where the "Truncated_packet 1", "Truncated_packet 2", ..., and "Truncated_packet N" result from truncating the Message Header, the Message Body and the Message Credential. Each "Message Envelope i" (inserted before each truncation) must set its TC flag to 1 and maintain the proper sequence count (in the <SequenceNumber>). Each "Message Envelope i" must also set its <MessageLength> to reflect the size of the packet. The recipient of these truncated packets can reassemble the message by concatenating these packets based on their <SequenceNumber>.
どこ、「「端が欠けている_パケット2インチ」_パケット1インチ先端を切られて、, そして、Message Header、Message Body、およびMessage Credentialに先端を切らせるのからの「端が欠けている_パケットN」結果。 各「メッセージEnvelope i」(各トランケーションの前に挿入される)は、TC旗を1に設定して、適切な系列カウント(<SequenceNumber>の)を維持しなければなりません。 また、各「メッセージEnvelope i」は、<MessageLength>にパケットのサイズを反映するように設定しなければなりません。 これらの端が欠けているパケットの受取人は、それらの<SequenceNumber>に基づくこれらのパケットを連結することによって、メッセージを組み立て直すことができます。
3. Handle Protocol Operations
3. プロトコル操作を扱ってください。
This section describes the details of each protocol operation in terms of messages exchanged between the client and server. It also defines the format of the Message Body according to each <OpCode> and <ResponseCode> in the Message Header.
このセクションはクライアントとサーバの間で交換されたメッセージに関してそれぞれのプロトコル操作の詳細について説明します。また、それぞれの<OpCode>と<ResponseCode>に従って、それはMessage HeaderでMessage Bodyの書式を定義します。
3.1. Client Bootstrapping
3.1. クライアントブートストラップ法
3.1.1. Global Handle Registry and its Service Information
3.1.1. グローバルなHandle RegistryとそのService情報
The service information for the Global Handle Registry (GHR) allows clients to contact the GHR to find out the responsible service components for their handles. The service information is a set of HS_SITE values assigned to the root handle "0.NA/0.NA" and is also
Global Handle Registry(GHR)のためのサービス情報で、クライアントは、それらのハンドルのために原因となるサービスコンポーネントを見つけるためにGHRに連絡できます。 サービス情報は_SITEが"0.NA/0.NA"を根のハンドルに割り当てて、また、割り当てたのを評価するHSの1セットです。
Sun, et al. Informational [Page 21] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[21ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
called the root service information. The root service information may be distributed along with the client software, or be downloaded from the Handle System website at http://www.handle.net.
根のサービス情報と呼ばれます。 根のサービス情報をクライアントソフトウェアと共に分配するか、または http://www.handle.net のHandle Systemウェブサイトからダウンロードするかもしれません。
Changes to the root service information are identified by the <SerialNumber> in the HS_SITE values. A server at GHR can find out if the root service information used by the client is outdated by checking the <SerialNumber> in the client's request. The client should update the root service information if the <ResponseCode> of the response message is RC_EXPIRED_SITE_INFO. Clients may obtain the most up-to-date root service information from the root handle. The GHR must sign the root service information using the public key specified in the outdated service information (identified in the client's request) so that the client can validate the signature.
根のサービス情報への変化はHS_SITE値における<SerialNumber>によって特定されます。 GHRのサーバは、クライアントによって使用された根のサービス情報がクライアントの要求で<SerialNumber>をチェックすることによって時代遅れであるかどうか見つけることができます。 クライアントは応答メッセージの<ResponseCode>がRC_EXPIRED_SITE_INFOであるなら根のサービス情報をアップデートするべきです。 クライアントは根のハンドルから最も最新の根のサービス情報を得るかもしれません。 GHRは、根のサービスが情報であるとクライアントが署名を有効にすることができるように時代遅れのサービス情報(クライアントの要求では、特定される)で指定された公開鍵を使用することで署名しなければなりません。
3.1.2. Locating the Handle System Service Component
3.1.2. ハンドルシステムサービスの部品の場所を見つけます。
Each handle under the Handle System is managed by a unique handle service component (e.g., LHS). For any given handle, the responsible service component (and its service information) can be found from its naming authority handle. Before resolving any given handle, the client needs to find the responsible service component by querying the naming authority handle from the GHR.
ユニークなハンドルサービスの部品(例えば、LHS)によってHandle Systemの下の各ハンドルは管理されます。 どんな与えられたハンドルに関してはも、命名権威ハンドルから原因となるサービスコンポーネント(そして、サービス情報)を見つけることができます。 どんな与えられたハンドルも決議する前に、クライアントは、GHRから命名権威ハンドルについて質問することによって原因となるサービスコンポーネントを見つける必要があります。
For example, to find the responsible LHS for the handle "1000/abc", client software can query the GHR for the HS_SITE (or HS_SERV) values assigned to the naming authority handle "0.NA/1000". The set of HS_SITE values provides the service information of the LHS that manages every handle under the naming authority "1000". If no HS_SITE values are found, the client can check if there is any HS_SERV value assigned to the naming authority handle. The HS_SERV value provides the service handle that maintains the service information for the LHS. Service handles are used to manage the service information shared by different naming authorities.
例えば、ハンドル"1000/abc"に関して責任があるLHSを見つけるために、クライアントソフトウェアは命名権威ハンドル"0.NA/1000"に割り当てられたHS_SITE(または、HS_SERV)値のためにGHRについて質問できます。 HS_SITE値のセットは命名権威「1000」の下であらゆるハンドルを管理するLHSのサービス情報を提供します。 HS_SITE値が全く見つけられないなら、クライアントは、何か命名権威ハンドルに割り当てられたHS_SERV値があるかどうかチェックできます。 HS_SERV値はLHSのためのサービス情報を保守するサービスハンドルを提供します。 サービスハンドルは、異なった命名当局によって共有されたサービス情報を管理するのに使用されます。
It is possible that the naming authority handle requested by the client does not reside at the GHR. This happens when naming authority delegation takes place. Naming authority delegation happens when a naming authority delegates an LHS to manage all its child naming authorities. In this case, the delegating naming authority must contain the service information, a set of HS_NA_DELEGATE values, of the LHS that manages its child naming authorities.
クライアントによって要求された命名権威ハンドルがGHRに住んでいないのは、可能です。 権威を委譲と命名するのが行われると、これは起こります。 命名権威が、LHSが当局を任命するすべての子供を管理するのを代表として派遣するとき、権威を委譲と命名するのは起こります。 この場合、権威を命名する代表として派遣するのはサービス情報(HS_NA_DELEGATE値、当局を任命する子供を管理するLHSの1セット)を含まなければなりません。
All top-level naming authority handles must be registered and managed by the GHR. When a server at the GHR receives a request for a naming authority that has been delegated to an LHS, it must return a message with the <ResponseCode> set to RC_NA_DELEGATE, along with the
GHRは権威をハンドルと命名するすべてのトップレベルを、示されて、管理しなければなりません。 GHRのサーバがLHSへ代表として派遣された命名権威を求める要求を受け取るとき、それは<ResponseCode>セットがあるメッセージをRC_NA_DELEGATEに返さなければなりません。
Sun, et al. Informational [Page 22] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[22ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
HS_NA_DELAGATE values from the nearest ancestor naming authority. The client can query the LHS described by the HS_NA_DELAGATE values for the delegated naming authority handle. In practice, the ancestor naming authority should make itself available to any handle server within the GHR, by replicating itself at the time of delegation. This will prevent any cross-queries among handle servers (within a service site) when the naming authority in query and the ancestor naming authority do not hash into the same handle server.
権威を命名する最も近い先祖からのHS_NA_DELAGATE値。 クライアントは代表として派遣された命名権威のためのDELAGATE値が扱うHS_NA_によって説明されたLHSについて質問できます。 実際には、権威を命名する先祖はGHRの中でそれ自体をどんなハンドルサーバにも利用可能にするべきです、委譲時点でそれ自体を模写することによって。 これは質問における命名権威と権威を命名する先祖がそうしないときのハンドルサーバ(サービスサイトの中の)の中のどんな交差している質問ハッシュも同じハンドルサーバに防ぐでしょう。
3.1.3. Selecting the Responsible Server
3.1.3. 原因となるサーバを選択します。
Each handle service component is defined in terms of a set of HS_SITE values. Each of these HS_SITE values defines a service site within the service component. A service site may consist of a group of handle servers. For any given handle, the responsible handle server within the service component can be found following this procedure:
それぞれのハンドルサービスの部品は1セットのHS_SITE値で定義されます。 それぞれのこれらのHS_SITE値はサービスコンポーネントの中でサービスサイトを定義します。 サービスサイトはハンドルサーバのグループから成るかもしれません。 どんな与えられたハンドルに関してはも、この手順に従っているのをサービスコンポーネントの中の原因となるハンドルサーバを見つけることができます:
1. Select a preferred service site.
1. 都合のよいサービスサイトを選択してください。
Each service site is defined in terms of an HS_SITE value. The
HS_SITE value may contain a <Description> or other attributes
(under the <AttributeList>) to help the selection. Clients
must select the primary service site for any administrative
operations.
それぞれのサービスサイトはHS_SITE値で定義されます。 HS_SITE値は選択を助ける<記述>か他の属性(<AttributeList>の下の)を含むかもしれません。 クライアントはどんな管理操作のためにも一次業務サイトを選択しなければなりません。
2. Locate the responsible server within the service site.
2. サービスサイトの中で原因となるサーバの場所を見つけてください。
This can be done as follows: Convert every ASCII character in
the handle to its upper case. Calculate the MD5 hash of the
converted handle string according to the <HashOption> given in
the HS_SITE value. Take the last 4 bytes of the hash result as
a signed integer. Modulo the absolute value of the integer by
the <NumOfServer> given in the HS_SITE value. The result is
the sequence number of the <ServerRecord> listed in the HS_SITE
value. For example, if the result of the modulation is 2, the
third <ServerRecord> listed in the <HS_SITE> should be
selected. The <ServerRecord> defines the responsible handle
server for the given handle.
以下の通りこれができます: ハンドルのすべてのASCII文字を大文字に変換してください。 HS_SITE値で与えられている<HashOption>に従って、変換されたハンドルストリングのMD5ハッシュについて計算してください。 署名している整数としてハッシュ結果のベスト4バイト取ってください。 HS_SITEの<NumOfServer>当然のことによる整数の絶対値が評価する法。 結果はHS_SITE値で記載された<ServerRecord>の一連番号です。 例えば、変調の結果が2であるなら、<HS_SITE>に記載された3番目の<ServerRecord>は選択されるべきです。 <ServerRecord>は与えられたハンドルのために原因となるハンドルサーバを定義します。
3.2. Query Operation
3.2. 質問操作
A query operation consists of a client sending a query request to the responsible handle server and the server returning the query result to the client. Query requests are used to retrieve handle values assigned to any given handle.
質問操作は質問結果をクライアントに返す原因となるハンドルサーバとサーバに質問要求を送るクライアントから成ります。 質問要求は、どんな与えられたハンドルにも割り当てられたハンドル値を検索するのに使用されます。
Sun, et al. Informational [Page 23] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[23ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
3.2.1. Query Request
3.2.1. 質問要求
The Message Header of any query request must set its <OpCode> to OC_RESOLUTION (defined in section 2.2.2.1) and <ResponseCode> to 0.
どんな質問要求のMessage HeaderもOC_RESOLUTION(セクション2.2.2では、.1を定義する)への<OpCode>と0への<ResponseCode>を設定しなければなりません。
The Message Body for any query request is defined as follows:
どんな質問要求のためのMessage Bodyも以下の通り定義されます:
<Message Body of Query Request> ::= <Handle>
<IndexList>
<TypeList>
質問要求>の<メッセージボディー:、:= <ハンドル><IndexList><TypeList>。
where
どこ
<Handle>
A UTF8-String (as defined in section 2.1.4) that specifies
the handle to be resolved.
決議されるためにハンドルを指定する<ハンドル>A UTF8-ストリング(セクション2.1.4で定義されるように)。
<IndexList>
A 4-byte unsigned integer followed by an array of 4-byte
unsigned integers. The first integer indicates the number
of integers in the integer array. Each number in the
integer array is a handle value index and refers to a handle
value to be retrieved. The client sets the first integer to
zero (followed by an empty array) to ask for all the handle
values regardless of their index.
4バイトの符号のない整数が4バイトの符号のない整数の勢ぞろいを続けた<IndexList>A。 最初の整数は整数配列における、整数の数を示します。 整数配列における各数は、ハンドル価値指数であり、検索されるためにハンドル値について言及します。 クライアントは、それらのインデックスにかかわらずすべてのハンドル値を求めるために最初の整数をゼロに設定します(空の配列はあとに続いています)。
<TypeList>
A 4-byte unsigned integer followed by a list of UTF8-
Strings. The first integer indicates the number of
UTF8-Strings in the list that follows. Each UTF8-String in
the list specifies a data type. This tells the server to
return all handle values whose data type is listed in the
list. If a UTF8-String ends with the '.' (0x2E) character,
the server must return all handle values whose data type is
under the type hierarchy specified in the UTF8-String. The
<TypeList> may contain no UTF8-String if the first integer
is 0. In this case, the server must return all handle
values regardless of their data type.
4バイトの符号のない整数がUTF8ストリングのリストを続けた<TypeList>A。 最初の整数は従うリストのUTF8-ストリングの数を示します。 リストの各UTF8-ストリングはデータ型を指定します。 これは、データ型がリストにリストアップされているすべてのハンドル値を返すようにサーバに言います。 'UTF8-ストリングが終わる、'.'(0x2E)キャラクタ、サーバはデータ型がUTF8-ストリングで指定されたタイプ階層構造の下にあるすべてのハンドル値を返さなければなりません。 <TypeList>は最初の整数が0であるならUTF8-ストリングを全く含まないかもしれません。 この場合、サーバはそれらのデータ型にかかわらずすべてのハンドル値を返さなければなりません。
If a query request does not specify any index or data type and the PO flag (in the Message Header) is set, the server will return all the handle values that have the PUBLIC_READ permission. Clients can also send queries without the PO flag set. In this case, the server will return all the handle values with PUBLIC_READ permission and all the handle values with ADMIN_READ permission. If the query requests a specific handle value via the value index and the value does not have PUBLIC_READ permission, the server should accept the request (and authenticate the client) even if the request has its PO flag set.
質問要求がどんなインデックスやデータ型も指定しないで、PO旗(Message Headerの)が設定されると、サーバはPUBLIC_READ許可を持っているすべてのハンドル値を返すでしょう。 また、クライアントはPO旗のセットなしで質問を送ることができます。 この場合、サーバはPUBLIC_READ許可があるすべてのハンドル値とADMIN_READ許可があるすべてのハンドル値を返すでしょう。 質問が価値指数で特定のハンドル値を要求して、値にPUBLIC_READ許可がないなら、要求でPO旗を設定しても、サーバは要請を受け入れるべきです(クライアントを認証してください)。
Sun, et al. Informational [Page 24] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[24ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
If a query consists of a non-empty <IndexList> but an empty <TypeList>, the server should only return those handle values whose indexes are listed in the <IndexList>. Likewise, if a query consists of a non-empty <TypeList> but an empty <IndexList>, the server should only return those handle values whose data types are listed in the <TypeList>.
質問が非空の<IndexList>にもかかわらず、空の<TypeList>から成るなら、サーバはインデックスが<IndexList>に記載されているそれらのハンドル値を返すだけであるべきです。 同様に、質問が非空の<TypeList>にもかかわらず、空の<IndexList>から成る場合にだけ、サーバはデータ型が<TypeList>にリストアップされているそれらのハンドル値を返すべきです。
When both <IndexList> and <TypeList> fields are non-empty, the server should return all handle values whose indexes are listed in the <IndexList> AND all handle values whose data types are listed in the <TypeList>.
<IndexList>と<TypeList>分野の両方が非人影がないときに、サーバはインデックスが<IndexList>に記載されているすべてのハンドル値とデータ型が<TypeList>にリストアップされているすべてのハンドル値を返すべきです。
3.2.2. Successful Query Response
3.2.2. うまくいっている質問応答
The Message Header of any query response must set its <OpCode> to OC_RESOLUTION. A successful query response must set its <ResponseCode> to RC_SUCCESS.
どんな質問応答のMessage HeaderもOC_RESOLUTIONに<OpCode>を設定しなければなりません。 うまくいっている質問応答はRC_SUCCESSに<ResponseCode>を設定しなければなりません。
The message body of the successful query response is defined as follows:
うまくいっている質問応答のメッセージ本体は以下の通り定義されます:
<Message Body of Successful Query Response> ::= [<RequestDigest>]
<Handle>
<ValueList>
うまくいっている質問応答>の<メッセージボディー:、:= [<RequestDigest>] <ハンドル><ValueList>。
where
どこ
<RequestDigest>
Optional field as defined in section 2.2.3.
Optionalがセクション2.2.3で定義されるようにさばく<RequestDigest>。
<Handle>
A UTF8-String that specifies the handle queried by the
client.
クライアントによって質問されたハンドルを指定する<ハンドル>A UTF8-ストリング。
<ValueList>
A 4-byte unsigned integer followed by a list of handle
values. The integer specifies the number of handle values
in the list. The encoding of each handle value follows the
specification given in [2] (see section 3.1). The integer
is set to zero if there is no handle value that satisfies
the query.
4バイトの符号のない整数がリストで続いた<ValueList>Aは値を扱います。 整数はリストのハンドル値の数を指定します。 それぞれのハンドル価値のコード化は[2]で与えられた仕様に従います(セクション3.1を見てください)。 質問を満たすハンドル値が全くなければ、整数はゼロに設定されます。
Sun, et al. Informational [Page 25] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[25ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
3.2.3. Unsuccessful Query Response
3.2.3. 失敗の質問応答
If a server cannot fulfill a client's request, it must return an error message. The general format for any error message from the server is specified in section 3.3 of this document.
サーバがクライアントの要求を実現させることができないなら、それはエラーメッセージを返さなければなりません。 サーバからのどんなエラーメッセージのための一般形式もこのドキュメントのセクション3.3で指定されます。
For example, a server must return an error message if the queried handle does not exist in its database. The error message will have an empty message body and have its <ResponseCode> set to RC_HANDLE_NOT_FOUND.
例えば、質問されたハンドルがデータベースに存在していないなら、サーバはエラーメッセージを返さなければなりません。 エラーメッセージで、空のメッセージ本体を持っていて、_FOUNDではなく、RC_HANDLE_に<ResponseCode>を用意ができさせるでしょう。
Note that a server should NOT return an RC_HANDLE_NOT_FOUND message if the server is not responsible for the handle being queried. It is possible that the queried handle exists but is managed by another handle server (under some other handle service). When this happens, the server should either send a service referral (see section 3.4) or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP.
サーバが質問されるハンドルに原因とならないならサーバが_FOUNDメッセージではなく、RC_HANDLE_を返すべきでないことに注意してください。 質問されたハンドルが存在していますが、別のハンドルサーバ(ある他のハンドルサービスの下における)によって管理されるのは、可能です。 これが起こると、サーバは、サービス紹介(セクション3.4を見る)を送るべきであるか、または単に_RESPではなく、RC_SERVER_に用意ができている<ResponseCode>があるエラーメッセージを返すべきです。
The server may return an error message with <ResponseCode> set to RC_SERVER_BUSY if the server is too busy to process the request. Like RC_HANDLE_NOT_FOUND, an RC_SERVER_BUSY message also has an empty message body.
サーバはサーバが要求を処理できないくらい忙しいならRC_SERVER_BUSYに用意ができている<ResponseCode>があるエラーメッセージを返すかもしれません。 また、_FOUNDではなく、RC_HANDLE_のように、RC_SERVER_BUSYメッセージには、空のメッセージ本体があります。
Servers should return an RC_ACCESS_DENIED message if the request asks for a specific handle value (via the handle value index) that has neither PUBLIC_READ nor ADMIN_READ permission.
要求がPUBLIC_READもADMIN_READ許可も持っていない特定のハンドル値(ハンドル価値指数を通した)を求めるなら、サーバはRC_ACCESS_DENIEDメッセージを返すべきです。
A handle Server may ask its client to authenticate itself as the handle administrator during the resolution. This happens if any handle value in query has ADMIN_READ permission, but no PUBLIC_READ permission. Details of client authentication are described later in this document.
ハンドルServerは、解決の間、ハンドル管理者としてそれ自体を認証するようにクライアントに頼むかもしれません。 ADMIN_READ許可を持っていますが、質問におけるどんなハンドル値にも何かPUBLIC_READ許可はないなら、これが起こります。 クライアント認証の詳細は後で本書では説明されます。
3.3. Error Response from Server
3.3. サーバからの誤り応答
A handle server will return an error message if it encounters an error when processing a request. Any error response from the server must maintain the same <OpCode> (in the message header) as the one in the original request. Each error condition is identified by a unique <ResponseCode> as defined in section 2.2.2.2 of this document.
要求を処理するとき、誤りに遭遇すると、ハンドルサーバはエラーメッセージを返すでしょう。 サーバからのどんな誤り応答もオリジナルの要求におけるものとして同じ<OpCode>を維持しなければなりません(メッセージヘッダーで)。 セクション2.2.2でこの.2通のドキュメントを定義するとき、各エラー条件はユニークな<ResponseCode>によって特定されます。
Sun, et al. Informational [Page 26] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[26ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
The Message Body of an error message may be empty. Otherwise it consists of the following data fields (unless otherwise specified):
エラーメッセージのMessage Bodyは空であるかもしれません。 さもなければ、以下のデータ・フィールドから成ります(別の方法で指定されない場合):
<Message Body of Error Response from Server> ::= [<RequestDigest>]
<ErrorMessage>
[ <IndexList> ]
サーバ>からの誤り応答の<メッセージボディー:、:= [<RequestDigest>] <ErrorMessage>。[<IndexList>]
where
どこ
<RequestDigest>
Optional field as defined in section 2.2.3.
Optionalがセクション2.2.3で定義されるようにさばく<RequestDigest>。
<ErrorMessage>
A UTF8-String that explains the error.
誤りがわかる<ErrorMessage>A UTF8-ストリング。
<IndexList>
An optional field. When not empty, it consists of a 4-byte
unsigned integer followed by a list of handle value indexes.
The first integer indicates the number of indexes in the
list. Each index in the list is a 4-byte unsigned integer
that refers to a handle value that contributed to the error.
An example would be a server that is asked to add three
handle values, with indexes 1, 2, and 3, and handle values
with indexes of 1 and 2 already in existence. In this case,
the server could return an error message with <REsponseCode>
set to RC_VALUE_ALREADY_EXIST and add index 1 and 2 to the
<IndexList>. Note that the server is not obligated to
return the complete list of handle value indexes that may
have caused the error.
<のIndexListの>のAnの任意の分野。 空でないときに、それはハンドル価値指数のリストがあとに続いた4バイトの符号のない整数から成ります。 最初の整数はリストのインデックスの数を示します。 リストの各インデックスは誤りに貢献したハンドル値について言及する4バイトの符号のない整数です。 例はインデックス1、2、および3で3が値を扱うと言い足して、1と2のインデックスが既に現存していた状態で値を扱うように頼まれるサーバでしょう。 この場合、サーバは、RC_VALUE_ALREADY_EXISTに用意ができている<REsponseCode>でエラーメッセージを返して、<IndexList>にインデックス1と2を加えるかもしれません。 サーバが誤りを引き起こしたかもしれないハンドル価値指数に関する全リストを返すのが義務付けられないことに注意してください。
3.4. Service Referral
3.4. サービス紹介
A handle server may receive requests for handles that are managed by some other handle server or service. When this happens, the server has the option to either return a referral message that directs the client to the proper handle service, or simply return an error message with <ResponseCode> set to RC_SERVER_NOT_RESP. Service referral also happens when ownership of handles moves from one handle service to another. It may also be used by any local handle service to delegate its service into multiple service layers.
ハンドルサーバはある他のハンドルサーバかサービスで管理されるハンドルを求める要求を受け取るかもしれません。 これが起こると、サーバは、どちらかへのオプションがクライアントを指示する紹介メッセージを適切なハンドルサービスに返すか、または_RESPではなく、RC_SERVER_に用意ができている<ResponseCode>で単にエラーメッセージを返すのをさせます。 また、ハンドルの所有権が別のものに対する1つのハンドルサービスから移行すると、サービス紹介は起こります。 また、それは、複数のサービス層の中へサービスを代表として派遣するのにどんな地方のハンドルサービスでも使用されるかもしれません。
The Message Header of a service referral must maintain the same <OpCode> as the one in the original request and set its <ResponseCode> to RC_SERVICE_REFERRAL.
サービス紹介のMessage Headerは、オリジナルの要求とセットにおけるものと同じ<OpCode>が<ResponseCode>であることをRC_SERVICE_REFERRALに支持しなければなりません。
Sun, et al. Informational [Page 27] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[27ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
The Message Body of any service referral is defined as follows:
どんなサービス紹介のMessage Bodyも以下の通り定義されます:
<Message Body of Service Referral> ::= [ <RequestDigest> ]
<ReferralHandle>
[ <ValueList> ]
サービス紹介>の<メッセージボディー:、:= [<RequestDigest>] <ReferralHandle>。[<ValueList>]
where
どこ
<RequestDigest>
Optional field as defined in section 2.2.3.
Optionalがセクション2.2.3で定義されるようにさばく<RequestDigest>。
<ReferralHandle>
A UTF8-String that identifies the handle (e.g., a service
handle) that maintains the referral information (i.e., the
service information of the handle service in which this
refers). If the <ReferralHandle> is set to "0.NA/0.NA",
it is referring the client to the GHR.
紹介情報が(すなわち、これが参照されるハンドルサービスのサービス情報)であると主張するハンドル(例えば、サービスハンドル)を特定する<ReferralHandle>A UTF8-ストリング。 <ReferralHandle>が"0.NA/0.NA"に用意ができているなら、それはクライアントをGHRに差し向けています。
<ValueList>
An optional field that must be empty if the <ReferralHandle>
is provided. When not empty, it consists of a 4-byte
unsigned integer, followed by a list of HS_SITE values. The
integer specifies the number of HS_SITE values in the list.
<ReferralHandle>を提供するなら人影がないに違いない<ValueList>An任意の分野。 空でないときに、それはHS_SITE値のリストがあとに続いた4バイトの符号のない整数から成ります。 整数はリストのHS_SITE値の数を指定します。
Unlike regular query responses that may consist of handle values of any data type, a service referral can only have zero or more HS_SITE values in its <ValueList>. The <ReferralHandle> may contain an empty UTF8-String if the HS_SITE values in the <ValueList> are not maintained by any handle.
どんなデータ型のハンドル値からも成るかもしれない定期的な質問応答と異なって、サービス紹介がゼロを持つことができるだけですか、または、より多くのHS_SITEが<でValueList>を評価します。 <ValueList>のHS_SITE値がどんなハンドルによっても維持されないなら、<ReferralHandle>は空のUTF8-ストリングを含むかもしれません。
Care must be taken by clients to avoid any loops caused by service referrals. It is also the client's responsibility to authenticate the service information obtained from the service referral. A client should always use its own copy of the GHR service information if the <ReferralHandle> is set to "0.NA/0.NA".
クライアントは、サービス紹介で引き起こされたどんな輪も避けるために注意しなければなりません。 サービス紹介から得られたサービス情報を認証するのは、クライアントのも責任です。 <ReferralHandle>が"0.NA/0.NA"に用意ができているなら、クライアントはいつもそれ自身のGHRサービス情報のコピーを使用するべきです。
3.5. Client Authentication
3.5. クライアント認証
Clients are asked to authenticate themselves as handle administrators when querying for any handle value with ADMIN_READ but no PUBLIC_READ permission. Client authentication is also required for any handle administration requests that require administrator privileges. This includes adding, removing, or modifying handles or handle values.
ADMIN_READがある値について質問しますが、どんなハンドルのためにもどんなPUBLIC_READ許可も質問しないとき、クライアントがハンドル管理者として自分たちを認証するように頼まれます。 また、クライアント認証が管理者特権を必要とするどんなハンドル管理要求にも必要です。 これは、ハンドルかハンドル値を加えるか、取り外すか、または変更するのを含んでいます。
Client authentication consists of multiple messages exchanged between the client and server. Such messages include the challenge from the server to the client to authenticate the client, the challenge- response from the client in response to the server's challenge, and
クライアント認証はクライアントとサーバの間で交換された複数のメッセージから成ります。そしてそのようなメッセージがサーバの挑戦に対応してクライアントからクライアント、挑戦応答を認証するためにサーバからクライアントまでの挑戦を含んでいる。
Sun, et al. Informational [Page 28] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[28ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
the verification request and response message if secret key authentication takes place. Messages exchanged during the authentication are correlated via a unique <SessionId> assigned by the server. For each authentication session, the server needs to maintain the state information that includes the server's challenge, the challenge-response from the client, as well as the original client request.
そして、検証要求、応答メッセージは秘密鍵認証であるなら行われます。 認証の間に交換されたメッセージはサーバによって割り当てられたユニークな<SessionId>を通して関連します。それぞれの認証セッションに、サーバは、サーバの挑戦を含んでいる州の情報を保守する必要があります、クライアントからのチャレンジレスポンス、オリジナルのクライアント要求と同様に。
The authentication starts with a response message from the server that contains a challenge to the client. The client must respond to the challenge with a challenge-response message. The server validates the challenge-response, either by verifying the digital signature inside the challenge-response, or by sending a verification request to another handle server (herein referred to as the verification server), that maintains the secret key for the administrator. The purpose of the challenge and the challenge- response is to prove to the server that the client possesses the private key (or the secret key) of the handle administrator. If the authentication fails, an error response will be sent back with the <ResponseCode> set to RC_AUTHEN_FAILED.
認証はクライアントへの挑戦を含むサーバから応答メッセージから始まります。 クライアントはチャレンジレスポンスメッセージで挑戦に応じなければなりません。 サーバは管理者のために秘密鍵を維持するチャレンジレスポンスでデジタル署名について確かめるか、または別のハンドルサーバに検証要求を送るのによるチャレンジレスポンス(ここに検証サーバと呼ばれる)を有効にします。 挑戦の目的と挑戦応答はクライアントにはハンドル管理者の秘密鍵(または、秘密鍵)があるとサーバに立証することです。 認証が失敗すると、誤り応答は<ResponseCode>セットでRC_AUTHEN_FAILEDに返送されるでしょう。
Upon successful client authentication, the server must also make sure that the administrator is authorized for the request. If the administrator has sufficient privileges, the server will process the request and send back the result. If the administrator does not have sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED.
また、うまくいっているクライアント認証のときに、サーバは、管理者が要求のために権限を与えられるのを確実にしなければなりません。 管理者に十分な特権があると、サーバは、要求を処理して、結果を返送するでしょう。 管理者に十分な特権がないと、サーバは<ResponseCode>がRCにセットしたことでのエラーメッセージに__どんなAUTHORIZEDも返さないでしょう。
The following sections provide details of each message exchanged during the authentication process.
以下のセクションは認証過程の間に交換されたそれぞれのメッセージの詳細を明らかにします。
3.5.1. Challenge from Server to Client
3.5.1. サーバからクライアントまでの挑戦
The Message Header of the CHALLENGE must keep the same <OpCode> as the original request and set the <ResponseCode> to RC_AUTH_NEEDED. The server must assign a non-zero unique <SessionId> in the Message Envelope to keep track of the authentication. It must also set the RD flag of the <OpFlag> (see section 2.2.2.3) in the Message Header, regardless of whether the original request had the RD bit set or not.
CHALLENGEのMessage Headerはオリジナルの要求として同じ<がOpCode>であることを保って、AUTH_が必要としたRC_に<ResponseCode>を設定しなければなりません。 サーバは、認証の動向をおさえるためにMessage Envelopeで非ゼロのユニークな<SessionId>を割り当てなければなりません。 それはそうしなければなりません、また、<OpFlag>のRD旗を設定してください。(Message Headerオリジナルの要求でRDビットを設定したかどうかにかかわらず.3である)か否かに関係なく、セクション2.2.2を見てください。
Sun, et al. Informational [Page 29] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[29ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
The Message Body of the server's CHALLENGE is defined as follows:
サーバのCHALLENGEのMessage Bodyは以下の通り定義されます:
<Message Body of Server's Challenge> ::= <RequestDigest>
<Nonce>
where
サーバの挑戦>の<メッセージボディー:、:= <RequestDigest><Nonce>、どこ
<RequestDigest>
Message Digest of the request message, as defined in section
2.2.3.
セクション2.2.3で定義されるような要求メッセージの<RequestDigest>Message Digest。
<Nonce>
A 4-byte unsigned integer followed by a random string
generated by the server via a secure random number
generator. The integer specifies the number of octets in
the random string. The size of the random string should be
no less than 20 octets.
4バイトの符号のない整数が安全な乱数発生器を通してサーバによって生成された無作為のストリングを続けた<の一回だけの>A。 整数は無作為のストリングの八重奏の数を指定します。 無作為のストリングのサイズは少なくとも20の八重奏であるべきです。
Note that the server will not sign the challenge if the client did not request the server to do so. If the client worries about whether it is speaking to the right server, it may ask the server to sign the <Challenge>. If the client requested the server to sign the <Challenge> but failed to validate the server's signature, the client should discard the server's response and reissue the request to the server.
クライアントが、そうするようサーバに要求しなかったならサーバが挑戦に署名しないことに注意してください。 クライアントがそれが正しいサーバと話しているかどうかを心配するなら、それは、<Challengeが>であると署名するようにサーバに頼むかもしれません。 クライアントが<Challengeが>であると署名するようサーバに要求しますが、サーバの署名を有効にしないなら、クライアントは、サーバの応答を捨てて、サーバに要求を再発行するでしょうに。
3.5.2. Challenge-Response from Client to Server
3.5.2. クライアントからサーバまでのチャレンジレスポンス
The Message Header of the CHALLENGE_RESPONSE must set its <OpCode> to OC_CHALLENGE_RESPONSE and its <ResponseCode> to 0. It must also keep the same <SessionId> (in the Message Envelope) as specified in the challenge from the server.
CHALLENGE_RESPONSEのMessage HeaderはOC_CHALLENGE_RESPONSEへの<OpCode>と0へのその<ResponseCode>を設定しなければなりません。 また、それは、サーバから同じ<が指定されるとして挑戦でSessionId>(Message Envelopeの)であることを保たなければなりません。
The Message Body of the CHALLENGE_RESPONSE request is defines as follows:
_RESPONSEがあるよう要求するCHALLENGEのMessage Bodyは以下の通り以下を定義します。
<Message Body of CHALLENGE_RESPONSE> ::= <AuthenticationType>
<KeyHandle>
<KeyIndex>
<ChallengeResponse>
挑戦_応答>の<メッセージボディー:、:= <AuthenticationType><KeyHandle><KeyIndex><ChallengeResponse>。
where
どこ
<AuthenticationType>
A UTF8-String that identifies the type of authentication key
used by the client. For example, the field is set to
"HS_SECKEY" if the client chooses to use a secret key for
its authentication. The field is set to "HS_PUBKEY" if a
public key is used instead.
クライアントによって使用された認証キーのタイプを特定する<AuthenticationType>A UTF8-ストリング。 例えば、クライアントが、認証に秘密鍵を使用するのを選ぶなら、分野は「HS_SECKEY」に設定されます。 公開鍵が代わりに使用されるなら、分野は「HS_PUBKEY」に設定されます。
Sun, et al. Informational [Page 30] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 30] RFC 3652 Handle System Protocol (v2.1) November 2003
<KeyHandle>
A UTF8-String that identifies the handle that holds the
public or secret key of the handle administrator.
<KeyHandle> A UTF8-String that identifies the handle that holds the public or secret key of the handle administrator.
<KeyIndex>
A 4-byte unsigned integer that specifies the index of the
handle value (of the <KeyHandle>) that holds the public or
secret key of the administrator.
<KeyIndex> A 4-byte unsigned integer that specifies the index of the handle value (of the <KeyHandle>) that holds the public or secret key of the administrator.
<ChallengeResponse>
Contains either the Message Authentication Code (MAC) or the
digital signature over the challenge from the server. If
the <AuthenticationType> is "HS_SECKEY", the
<ChallengeResponse> consists of an octet followed by the
MAC. The octet identifies the algorithm used to generate
the MAC. For example, if the first octet is set to 0x01,
the MAC is generated by
<ChallengeResponse> Contains either the Message Authentication Code (MAC) or the digital signature over the challenge from the server. If the <AuthenticationType> is "HS_SECKEY", the <ChallengeResponse> consists of an octet followed by the MAC. The octet identifies the algorithm used to generate the MAC. For example, if the first octet is set to 0x01, the MAC is generated by
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
MD5_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
where the <SecretKey> is the administrator's secret key
referenced by the <KeyHandle> and <KeyIndex>. The
<ServerChallenge> is the Message Body portion of the
server's challenge. If the first octet in the
<ChallengeResponse> is set to 0x02, the MAC is generated
using
where the <SecretKey> is the administrator's secret key referenced by the <KeyHandle> and <KeyIndex>. The <ServerChallenge> is the Message Body portion of the server's challenge. If the first octet in the <ChallengeResponse> is set to 0x02, the MAC is generated using
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
SHA-1_Hash(<SecretKey> + <ServerChallenge> + <SecretKey>)
A more secure approach is to use HMAC [17] for the
<ChallengeResponse>. The HMAC can be generated using the
<SecretKey> and <ServerChallenge>. A <ChallengeResponse>
with its first octet set to 0x11 indicates that the HMAC
is generated using the MD5 algorithm. Likewise, a
<ChallengeResponse> with its first octet set to 0x12
indicates that the HMAC is generated using the SHA-1
algorithm.
A more secure approach is to use HMAC [17] for the <ChallengeResponse>. The HMAC can be generated using the <SecretKey> and <ServerChallenge>. A <ChallengeResponse> with its first octet set to 0x11 indicates that the HMAC is generated using the MD5 algorithm. Likewise, a <ChallengeResponse> with its first octet set to 0x12 indicates that the HMAC is generated using the SHA-1 algorithm.
If the <AuthenticationType> is "HS_PUBKEY", the
<ChallengeResponse> contains the digital signature over the
Message Body portion of the server's challenge. The
signature is generated in two steps: First, a one-way hash
value is computed over the blob that is to be signed.
Second, the hash value is signed using the private key.
The signature consists of a UTF8-String that specifies the
digest algorithm used for the signature, followed by the
signature over the server's challenge. The <KeyHandle> and
If the <AuthenticationType> is "HS_PUBKEY", the <ChallengeResponse> contains the digital signature over the Message Body portion of the server's challenge. The signature is generated in two steps: First, a one-way hash value is computed over the blob that is to be signed. Second, the hash value is signed using the private key. The signature consists of a UTF8-String that specifies the digest algorithm used for the signature, followed by the signature over the server's challenge. The <KeyHandle> and
Sun, et al. Informational [Page 31] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 31] RFC 3652 Handle System Protocol (v2.1) November 2003
<KeyIndex> refers to the administrator's public key that can
be used to verify the signature.
<KeyIndex> refers to the administrator's public key that can be used to verify the signature.
Handle administrators are defined in terms of HS_ADMIN values assigned to the handle. Each HS_ADMIN value defines the set of privileges granted to the administrator. It also provides the reference to the authentication key that can be used to authenticate the administrator. The reference can be made directly if the <AdminRef> field of the HS_ADMIN value refers to the handle value that holds the authentication key. Indirect reference to the authentication key can also be made via administrator groups. In this case, the <AdminRef> field may refer to a handle value of type HS_VLIST. An HS_VLIST value defines an administrator group via a list of handle value references, each of which refers to the authentication key of a handle administrator.
Handle administrators are defined in terms of HS_ADMIN values assigned to the handle. Each HS_ADMIN value defines the set of privileges granted to the administrator. It also provides the reference to the authentication key that can be used to authenticate the administrator. The reference can be made directly if the <AdminRef> field of the HS_ADMIN value refers to the handle value that holds the authentication key. Indirect reference to the authentication key can also be made via administrator groups. In this case, the <AdminRef> field may refer to a handle value of type HS_VLIST. An HS_VLIST value defines an administrator group via a list of handle value references, each of which refers to the authentication key of a handle administrator.
For handles with multiple HS_ADMIN values, the server will have to check each of those with sufficient privileges to see if its <AdminRef> field matches the <KeyHandle> and <KeyIndex>. If no match is found, but there are administrator groups defined, the server must check if the <KeyHandle> and <KeyIndex> belong to any of the administrator groups that have sufficient privileges. An administrator group may contain another administrator group as a member. Servers must be careful to avoid infinite loops when navigating these groups.
For handles with multiple HS_ADMIN values, the server will have to check each of those with sufficient privileges to see if its <AdminRef> field matches the <KeyHandle> and <KeyIndex>. If no match is found, but there are administrator groups defined, the server must check if the <KeyHandle> and <KeyIndex> belong to any of the administrator groups that have sufficient privileges. An administrator group may contain another administrator group as a member. Servers must be careful to avoid infinite loops when navigating these groups.
If the <KeyHandle> and <KeyIndex> are not referenced by any of the HS_ADMIN values, or the administrator group that has sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED. Otherwise, the server will continue to authenticate the client as follows:
If the <KeyHandle> and <KeyIndex> are not referenced by any of the HS_ADMIN values, or the administrator group that has sufficient privileges, the server will return an error message with <ResponseCode> set to RC_NOT_AUTHORIZED. Otherwise, the server will continue to authenticate the client as follows:
If the <AuthenticationType> is "HS_PUBKEY", the server will retrieve the administrator's public key based on the <KeyHandle> and <KeyIndex>. The public key can be used to verify the <ChallengeResponse> against the server's <Challenge>. If the <ChallengeResponse> matches the <Challenge>, the server will continue to process the original request and return the result. Otherwise, the server will return an error message with <ResponseCode> set to RC_AUTHENTICATION_FAILED.
If the <AuthenticationType> is "HS_PUBKEY", the server will retrieve the administrator's public key based on the <KeyHandle> and <KeyIndex>. The public key can be used to verify the <ChallengeResponse> against the server's <Challenge>. If the <ChallengeResponse> matches the <Challenge>, the server will continue to process the original request and return the result. Otherwise, the server will return an error message with <ResponseCode> set to RC_AUTHENTICATION_FAILED.
If the <AuthenticationType> is "HS_SECKEY", the server will have to send a verification request to the verification server; that is, the handle server that manages the handle referenced by the <KeyHandle>. The verification request and its response are defined in the following sections. The verification server will verify the <ChallengeResponse> against the <Challenge> on behalf of the handle server.
If the <AuthenticationType> is "HS_SECKEY", the server will have to send a verification request to the verification server; that is, the handle server that manages the handle referenced by the <KeyHandle>. The verification request and its response are defined in the following sections. The verification server will verify the <ChallengeResponse> against the <Challenge> on behalf of the handle server.
Sun, et al. Informational [Page 32] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 32] RFC 3652 Handle System Protocol (v2.1) November 2003
3.5.3. Challenge-Response Verification-Request
3.5.3. Challenge-Response Verification-Request
The message header of the VERIFICATION_REQUEST must set its <OpCode> to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
The message header of the VERIFICATION_REQUEST must set its <OpCode> to OC_VERIFY_CHALLENGE and the <ResponseCode> to 0.
The message body of the Verification-Request is defined as follows:
The message body of the Verification-Request is defined as follows:
<Message Body of VERIFICATION_REQUEST> ::= <KeyHandle>
<KeyIndex>
<Challenge>
<ChallengeResponse>
<Message Body of VERIFICATION_REQUEST> ::= <KeyHandle> <KeyIndex> <Challenge> <ChallengeResponse>
where
where
<KeyHandle>
A UTF8-String that refers to the handle that holds the
secret key of the administrator.
<KeyHandle> A UTF8-String that refers to the handle that holds the secret key of the administrator.
<KeyIndex>
A 4-byte unsigned integer that is the index of the handle
value that holds the secret key of the administrator.
<KeyIndex> A 4-byte unsigned integer that is the index of the handle value that holds the secret key of the administrator.
<Challenge>
The message body of the server's challenge, as described in
section 3.5.1.
<Challenge> The message body of the server's challenge, as described in section 3.5.1.
<ChallengeResponse>
The <ChallengeResponse> from the client in response to
the server's <Challenge>, as defined in section 3.5.2.
<ChallengeResponse> The <ChallengeResponse> from the client in response to the server's <Challenge>, as defined in section 3.5.2.
Any Challenge-Response Verification-Request must set its CT bit in the message header. This is to ensure that the verification server will sign the Verification-Response as specified in the next section.
Any Challenge-Response Verification-Request must set its CT bit in the message header. This is to ensure that the verification server will sign the Verification-Response as specified in the next section.
3.5.4. Challenge-Response Verification-Response
3.5.4. Challenge-Response Verification-Response
The Verification-Response tells the requesting handle server whether the <ChallengeResponse> matches the <Challenge> in the Verification- Request.
The Verification-Response tells the requesting handle server whether the <ChallengeResponse> matches the <Challenge> in the Verification- Request.
The Message Header of the Verification-Response must set its <ResponseCode> to RC_SUCCESS whether or not the <ChallengeResponse> matches the <Challenge>. The RD flag in the <OpFlag> field should also be set (to 1) since the <RequestDigist> will be mandatory in the Message Body.
The Message Header of the Verification-Response must set its <ResponseCode> to RC_SUCCESS whether or not the <ChallengeResponse> matches the <Challenge>. The RD flag in the <OpFlag> field should also be set (to 1) since the <RequestDigist> will be mandatory in the Message Body.
Sun, et al. Informational [Page 33] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 33] RFC 3652 Handle System Protocol (v2.1) November 2003
The Message Body of the Verification-Response is defined as follows:
The Message Body of the Verification-Response is defined as follows:
<Challenge-Response Verification-Response>
::= <RequestDigest>
<VerificationResult>
where
<Challenge-Response Verification-Response> ::= <RequestDigest> <VerificationResult> where
<RequestDigest>
Contains the message digest of the Verification-Request.
<RequestDigest> Contains the message digest of the Verification-Request.
<VerificationResult>
An octet that is set to 1 if the <ChallengeResponse>
matches the <Challenge>. Otherwise it must be set to
0.
<VerificationResult> An octet that is set to 1 if the <ChallengeResponse> matches the <Challenge>. Otherwise it must be set to 0.
The verification server may return an error with <ResponseCode> set to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the <KeyHandle> does not exist, or the <KeyHandle> and <KeyIndex> refer to an invalid handle value). When this happens, the server that performs the client authentication should relay the same error message back to the client.
The verification server may return an error with <ResponseCode> set to RC_AUTHEN_FAILED if it cannot perform the verification (e.g., the <KeyHandle> does not exist, or the <KeyHandle> and <KeyIndex> refer to an invalid handle value). When this happens, the server that performs the client authentication should relay the same error message back to the client.
3.6. Handle Administration
3.6. Handle Administration
The Handle System protocol supports a set of handle administration functions that include adding, deleting, and modifying handles or handle values. Before fulfilling any administration request, the server must authenticate the client as the handle administrator that is authorized for the administrative operation. Handle administration can only be carried out by the primary handle server.
The Handle System protocol supports a set of handle administration functions that include adding, deleting, and modifying handles or handle values. Before fulfilling any administration request, the server must authenticate the client as the handle administrator that is authorized for the administrative operation. Handle administration can only be carried out by the primary handle server.
3.6.1. Add Handle Value(s)
3.6.1. Add Handle Value(s)
Clients add values to existing handles by sending ADD_VALUE requests to the responsible handle server. The Message Header of the ADD_VALUE request must set its <OpCode> to OC_ADD_VALUE.
Clients add values to existing handles by sending ADD_VALUE requests to the responsible handle server. The Message Header of the ADD_VALUE request must set its <OpCode> to OC_ADD_VALUE.
The Message Body of the ADD_VALUE request is encoded as follows:
The Message Body of the ADD_VALUE request is encoded as follows:
<Message Body of ADD_VALUE Request> ::= <Handle>
<ValueList>
<Message Body of ADD_VALUE Request> ::= <Handle> <ValueList>
where
where
<Handle>
A UTF8-String that specifies the handle.
<Handle> A UTF8-String that specifies the handle.
Sun, et al. Informational [Page 34] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 34] RFC 3652 Handle System Protocol (v2.1) November 2003
<ValueList>
A 4-byte unsigned integer followed by a list of handle
values. The integer indicates the number of handle values
in the list.
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list.
The server that receives the ADD_VALUE request must first authenticate the client as the administrator with the ADD_VALUE privilege. Upon successful authentication, the server will proceed to add each value in the <ValueList> to the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
The server that receives the ADD_VALUE request must first authenticate the client as the administrator with the ADD_VALUE privilege. Upon successful authentication, the server will proceed to add each value in the <ValueList> to the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
Each ADD_VALUE request must be carried out as a transaction. If adding any value in the <ValueList> raises an error, the entire operation must be rolled back. For any failed ADD_VALUE request, none of the values in the <ValueList> should be added to the <Handle>. The server must also send a response to the client that explains the error. For example, if a value in the <ValueList> has the same index as one of the existing handle values, the server will return an error message that has the <ResponseCode> set to RC_VALUE_ALREADY_EXISTS.
Each ADD_VALUE request must be carried out as a transaction. If adding any value in the <ValueList> raises an error, the entire operation must be rolled back. For any failed ADD_VALUE request, none of the values in the <ValueList> should be added to the <Handle>. The server must also send a response to the client that explains the error. For example, if a value in the <ValueList> has the same index as one of the existing handle values, the server will return an error message that has the <ResponseCode> set to RC_VALUE_ALREADY_EXISTS.
ADD_VALUE requests can also be used to add handle administrators. This happens if the <ValueList> in the ADD_VALUE request contains any HS_ADMIN values. The server must authenticate the client as an administrator with the ADD_ADMIN privilege before fulfilling such requests.
ADD_VALUE requests can also be used to add handle administrators. This happens if the <ValueList> in the ADD_VALUE request contains any HS_ADMIN values. The server must authenticate the client as an administrator with the ADD_ADMIN privilege before fulfilling such requests.
An ADD_VALUE request will result in an error if the requested handle does not exist. When this happens, the server will return an error message with <ResponseCode> set to RC_HANDLE_NOT_EXIST.
An ADD_VALUE request will result in an error if the requested handle does not exist. When this happens, the server will return an error message with <ResponseCode> set to RC_HANDLE_NOT_EXIST.
3.6.2. Remove Handle Value(s)
3.6.2. Remove Handle Value(s)
Clients remove existing handle values by sending REMOVE_VALUE requests to the responsible handle server. The Message Header of the REMOVE_VALUE request must set its <OpCode> to OC_REMOVE_VALUE.
Clients remove existing handle values by sending REMOVE_VALUE requests to the responsible handle server. The Message Header of the REMOVE_VALUE request must set its <OpCode> to OC_REMOVE_VALUE.
The Message Body of any REMOVE_VALUE request is encoded as follows:
The Message Body of any REMOVE_VALUE request is encoded as follows:
<Message Body of REMOVE_VALUE Request> ::= <Handle>
<IndexList>
<Message Body of REMOVE_VALUE Request> ::= <Handle> <IndexList>
where
where
<Handle>
A UTF8-String that specifies the handle whose value(s) needs
to be removed.
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be removed.
Sun, et al. Informational [Page 35] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 35] RFC 3652 Handle System Protocol (v2.1) November 2003
<IndexList>
A 4-byte unsigned integer followed by a list of handle value
indexes. Each index refers to a handle value to be removed
from the <Handle>. The integer specifies the number of
indexes in the list. Each index is also encoded as a 4-byte
unsigned integer.
<IndexList> A 4-byte unsigned integer followed by a list of handle value indexes. Each index refers to a handle value to be removed from the <Handle>. The integer specifies the number of indexes in the list. Each index is also encoded as a 4-byte unsigned integer.
The server that receives the REMOVE_VALUE request must first authenticate the client as the administrator with the REMOVE VALUE privilege. Upon successful authentication, the server will proceed to remove the handle values specified in the <IndexList> from the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
The server that receives the REMOVE_VALUE request must first authenticate the client as the administrator with the REMOVE VALUE privilege. Upon successful authentication, the server will proceed to remove the handle values specified in the <IndexList> from the <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
Each REMOVE_VALUE request must be carried out as a transaction. If removing any value specified in the <IndexList> raises an error, the entire operation must be rolled back. For any failed REMOVE_VALUE request, none of values referenced in the <IndexList> should be removed from the <Handle>. The server must also send a response to the client that explains the error. For example, attempts to remove any handle value with neither PUB_WRITE nor ADMIN_WRITE permission will result in an RC_ACCESS_DENIED error. Note that a REMOVE_VALUE request asking to remove a non-existing handle value will not be treated as an error.
Each REMOVE_VALUE request must be carried out as a transaction. If removing any value specified in the <IndexList> raises an error, the entire operation must be rolled back. For any failed REMOVE_VALUE request, none of values referenced in the <IndexList> should be removed from the <Handle>. The server must also send a response to the client that explains the error. For example, attempts to remove any handle value with neither PUB_WRITE nor ADMIN_WRITE permission will result in an RC_ACCESS_DENIED error. Note that a REMOVE_VALUE request asking to remove a non-existing handle value will not be treated as an error.
REMOVE_VALUE requests can also be used to remove handle administrators. This happens if any of the indexes in the <IndexList> refer to an HS_ADMIN value. Servers must authenticate the client as an administrator with the REMOVE_ADMIN privilege before fulfilling such requests.
REMOVE_VALUE requests can also be used to remove handle administrators. This happens if any of the indexes in the <IndexList> refer to an HS_ADMIN value. Servers must authenticate the client as an administrator with the REMOVE_ADMIN privilege before fulfilling such requests.
3.6.3. Modify Handle Value(s)
3.6.3. Modify Handle Value(s)
Clients can make modifications to an existing handle value by sending MODIFY_VALUE requests to the responsible handle server. The Message Header of the MODIFY_VALUE request must set its <OpCode> to OC_MODIFY_VALUE.
Clients can make modifications to an existing handle value by sending MODIFY_VALUE requests to the responsible handle server. The Message Header of the MODIFY_VALUE request must set its <OpCode> to OC_MODIFY_VALUE.
The Message Body of any MODIFY_VALUE request is defined as follows:
The Message Body of any MODIFY_VALUE request is defined as follows:
<Message Body of MODIFY_VALUE Response> ::= <Handle>
<ValueList>
<Message Body of MODIFY_VALUE Response> ::= <Handle> <ValueList>
where
where
<Handle>
A UTF8-String that specifies the handle whose value(s) needs
to be modified.
<Handle> A UTF8-String that specifies the handle whose value(s) needs to be modified.
Sun, et al. Informational [Page 36] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 36] RFC 3652 Handle System Protocol (v2.1) November 2003
<ValueList>
A 4-byte unsigned integer followed by a list of handle
values. The integer specifies the number of handle values
in the list. Each value in the <ValueList> specifies a
handle value that will replace the existing handle value
with the same index.
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer specifies the number of handle values in the list. Each value in the <ValueList> specifies a handle value that will replace the existing handle value with the same index.
The server that receives the MODIFY_VALUE request must first authenticate the client as an administrator with the MODIFY_VALUE privilege. Upon successful authentication, the server will proceed to replace those handle values listed in the <ValueList>, provided each handle value has PUB_WRITE or ADMIN_WRITE permission. If successful, the server must notify the client with an RC_SUCCESS message.
The server that receives the MODIFY_VALUE request must first authenticate the client as an administrator with the MODIFY_VALUE privilege. Upon successful authentication, the server will proceed to replace those handle values listed in the <ValueList>, provided each handle value has PUB_WRITE or ADMIN_WRITE permission. If successful, the server must notify the client with an RC_SUCCESS message.
Each MODIFY_VALUE request must be carried out as a transaction. If replacing any value listed in the <ValueList> raises an error, the entire operation must be rolled back. For any failed MODIFY_VALUE request, none of values in the <ValueList> should be replaced. The server must also return a response to the client that explains the error. For example, if a MODIFY_VALUE requests to remove a handle value that has neither PUB_WRITE nor ADMIN_WRITE permission, the server must return an error message with the <ResponseCode> set to RC_ACCESS_DENIED. Any MODIFY_VALUE request to replace non- existing handle values is also treated as an error. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_NOT_FOUND.
Each MODIFY_VALUE request must be carried out as a transaction. If replacing any value listed in the <ValueList> raises an error, the entire operation must be rolled back. For any failed MODIFY_VALUE request, none of values in the <ValueList> should be replaced. The server must also return a response to the client that explains the error. For example, if a MODIFY_VALUE requests to remove a handle value that has neither PUB_WRITE nor ADMIN_WRITE permission, the server must return an error message with the <ResponseCode> set to RC_ACCESS_DENIED. Any MODIFY_VALUE request to replace non- existing handle values is also treated as an error. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_NOT_FOUND.
MODIFY_VALUE requests can also be used to update handle administrators. This happens if both the values in the <ValueList> and the value to be replaced are HS_ADMIN values. Servers must authenticate the client as an administrator with the MODIFY_ADMIN privilege before fulfilling such a request. It is an error to replace a non-HS_ADMIN value with an HS_ADMIN value. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_INVALID.
MODIFY_VALUE requests can also be used to update handle administrators. This happens if both the values in the <ValueList> and the value to be replaced are HS_ADMIN values. Servers must authenticate the client as an administrator with the MODIFY_ADMIN privilege before fulfilling such a request. It is an error to replace a non-HS_ADMIN value with an HS_ADMIN value. In this case, the server will return an error message with <ResponseCode> set to RC_VALUE_INVALID.
3.6.4. Create Handle
3.6.4. Create Handle
Clients can create new handles by sending CREATE_HANDLE requests to the responsible handle server. The Message Header of any CREATE_HANDLE request must set its <OpCode> to OC_CREATE_HANDLE.
Clients can create new handles by sending CREATE_HANDLE requests to the responsible handle server. The Message Header of any CREATE_HANDLE request must set its <OpCode> to OC_CREATE_HANDLE.
Sun, et al. Informational [Page 37] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 37] RFC 3652 Handle System Protocol (v2.1) November 2003
The Message Body of any CREATE_HANDLE request is defined as follows:
The Message Body of any CREATE_HANDLE request is defined as follows:
<Message Body of CREATE_HANDLE Response> ::= <Handle>
<ValueList>
<Message Body of CREATE_HANDLE Response> ::= <Handle> <ValueList>
where
where
<Handle>
A UTF8-String that specifies the handle.
<Handle> A UTF8-String that specifies the handle.
<ValueList>
A 4-byte unsigned integer followed by a list of handle
values. The integer indicates the number of handle values
in the list. The <ValueList> should at least include one
HS_ADMIN value that defines the handle administrator.
<ValueList> A 4-byte unsigned integer followed by a list of handle values. The integer indicates the number of handle values in the list. The <ValueList> should at least include one HS_ADMIN value that defines the handle administrator.
Only naming authority administrators with the CREATE_HANDLE privilege are allowed to create new handles under the naming authority. The server that receives a CREATE_HANDLE request must authenticate the client as the administrator of the corresponding naming authority handle and make certain that the administrator is authorized to create handles under the naming authority. This is different from the ADD_VALUE request where the server authenticates the client as an administrator of the handle. Upon successful authentication, the server will proceed to create the new handle and add each value in the <ValueList> to the new <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
Only naming authority administrators with the CREATE_HANDLE privilege are allowed to create new handles under the naming authority. The server that receives a CREATE_HANDLE request must authenticate the client as the administrator of the corresponding naming authority handle and make certain that the administrator is authorized to create handles under the naming authority. This is different from the ADD_VALUE request where the server authenticates the client as an administrator of the handle. Upon successful authentication, the server will proceed to create the new handle and add each value in the <ValueList> to the new <Handle>. If successful, the server will return an RC_SUCCESS message to the client.
Each CREATE_HANDLE request must be carried out as a transaction. If any part of the CREATE_HANDLE process fails, the entire operation can be rolled back. For example, if the server fails to add values in the <ValueList> to the new handle, it must return an error message without creating the new handle. Any CREATE_HANDLE request that asks to create a handle that already exists will be treated as an error. In this case, the server will return an error message with the <ResponseCode> set to RC_HANDLE_ALREADY_EXIST.
Each CREATE_HANDLE request must be carried out as a transaction. If any part of the CREATE_HANDLE process fails, the entire operation can be rolled back. For example, if the server fails to add values in the <ValueList> to the new handle, it must return an error message without creating the new handle. Any CREATE_HANDLE request that asks to create a handle that already exists will be treated as an error. In this case, the server will return an error message with the <ResponseCode> set to RC_HANDLE_ALREADY_EXIST.
CREATE_HANDLE requests can also be used to create naming authorities. Naming authorities are created as naming authority handles at the GHR. Before creating a new naming authority handle, the server must authenticate the client as the administrator of the parent naming authority. Only administrators with the CREATE_NA privilege are allowed to create any sub-naming authority. Root level naming authorities may be created by the administrator of the root handle "0.NA/0.NA".
CREATE_HANDLE requests can also be used to create naming authorities. Naming authorities are created as naming authority handles at the GHR. Before creating a new naming authority handle, the server must authenticate the client as the administrator of the parent naming authority. Only administrators with the CREATE_NA privilege are allowed to create any sub-naming authority. Root level naming authorities may be created by the administrator of the root handle "0.NA/0.NA".
Sun, et al. Informational [Page 38] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 38] RFC 3652 Handle System Protocol (v2.1) November 2003
3.6.5. Delete Handle
3.6.5. Delete Handle
Clients delete existing handles by sending DELETE_HANDLE requests to the responsible handle server. The Message Header of the DELETE_HANDLE request must set its <OpCode> to OC_DELETE_HANDLE.
Clients delete existing handles by sending DELETE_HANDLE requests to the responsible handle server. The Message Header of the DELETE_HANDLE request must set its <OpCode> to OC_DELETE_HANDLE.
The Message Body of any DELETE_HANDLE request is defined as follows:
The Message Body of any DELETE_HANDLE request is defined as follows:
<Message Body of DELETE_HANDLE Request> ::= <Handle>
<Message Body of DELETE_HANDLE Request> ::= <Handle>
where
where
<Handle>
A UTF8-String that specifies the handle.
<Handle> A UTF8-String that specifies the handle.
The server that receives the DELETE_HANDLE request must first authenticate the client as the administrator with the DELETE_HANDLE privilege. Upon successful authentication, the server will proceed to delete the handle along with any handle values assigned to the handle. If successful, the server will return an RC_SUCCESS message to the client.
The server that receives the DELETE_HANDLE request must first authenticate the client as the administrator with the DELETE_HANDLE privilege. Upon successful authentication, the server will proceed to delete the handle along with any handle values assigned to the handle. If successful, the server will return an RC_SUCCESS message to the client.
Each DELETE_HANDLE request must be carried out as a transaction. If any part of the DELETE_HANDLE process fails, the entire operation must be rolled back. For example, if the server fails to remove any handle values assigned to the handle (before deleting the handle), it must return an error message without deleting the handle. This may happen if the handle contains a value that has neither PUB_WRITE nor ADMIN_WRITE permission. In this case, the server will return an error message with the <ResponseCode> set to RC_PERMISSION_DENIED. A DELETE_HANDLE request that asks to delete a non-existing handle will also be treated as an error. The server will return an error message with the <ResponseCode> set to RC_HANDLE_NOT_EXIST.
Each DELETE_HANDLE request must be carried out as a transaction. If any part of the DELETE_HANDLE process fails, the entire operation must be rolled back. For example, if the server fails to remove any handle values assigned to the handle (before deleting the handle), it must return an error message without deleting the handle. This may happen if the handle contains a value that has neither PUB_WRITE nor ADMIN_WRITE permission. In this case, the server will return an error message with the <ResponseCode> set to RC_PERMISSION_DENIED. A DELETE_HANDLE request that asks to delete a non-existing handle will also be treated as an error. The server will return an error message with the <ResponseCode> set to RC_HANDLE_NOT_EXIST.
DELETE_HANDLE requests can also be used to delete naming authorities. This is achieved by deleting the corresponding naming authority handle on the GHR. Before deleting a naming authority handle, the server must authenticate the client as the administrator of the naming authority handle. Only administrators with the DELETE_NA privilege are allowed to delete the naming authority. Root level naming authorities may be deleted by the administrator of the root handle "0.NA/0.NA".
DELETE_HANDLE requests can also be used to delete naming authorities. This is achieved by deleting the corresponding naming authority handle on the GHR. Before deleting a naming authority handle, the server must authenticate the client as the administrator of the naming authority handle. Only administrators with the DELETE_NA privilege are allowed to delete the naming authority. Root level naming authorities may be deleted by the administrator of the root handle "0.NA/0.NA".
Sun, et al. Informational [Page 39] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 39] RFC 3652 Handle System Protocol (v2.1) November 2003
3.7. Naming Authority (NA) Administration
3.7. Naming Authority (NA) Administration
The Handle System manages naming authorities via naming authority handles. Naming authority handles are managed by the GHR. Clients can change the service information of any naming authority by changing the HS_SITE values assigned to the corresponding naming authority handle. Creating or deleting naming authorities is done by creating or deleting the corresponding naming authority handles. Root level naming authorities may be created or deleted by the administrator of the root handle "0.NA/0.NA". Non-root-level naming authorities may be created by the administrator of its parent naming authority.
The Handle System manages naming authorities via naming authority handles. Naming authority handles are managed by the GHR. Clients can change the service information of any naming authority by changing the HS_SITE values assigned to the corresponding naming authority handle. Creating or deleting naming authorities is done by creating or deleting the corresponding naming authority handles. Root level naming authorities may be created or deleted by the administrator of the root handle "0.NA/0.NA". Non-root-level naming authorities may be created by the administrator of its parent naming authority.
For example, the administrator of the naming authority handle "0.NA/10" may create the naming authority "10.1000" by sending a CREATE_HANDLE request to the GHR to create the naming authority handle "0.NA/10.1000". Before fulfilling the request, the server at the GHR must authenticate the client as the administrator of the parent naming authority, that is, the administrator of the naming authority handle "0.NA/10". The server must also make sure that the administrator has the NA_CREATE privilege.
For example, the administrator of the naming authority handle "0.NA/10" may create the naming authority "10.1000" by sending a CREATE_HANDLE request to the GHR to create the naming authority handle "0.NA/10.1000". Before fulfilling the request, the server at the GHR must authenticate the client as the administrator of the parent naming authority, that is, the administrator of the naming authority handle "0.NA/10". The server must also make sure that the administrator has the NA_CREATE privilege.
The Handle protocol also allows clients to list handles or sub-naming authorities under a naming authority. Details of these operations are described in the following sections.
The Handle protocol also allows clients to list handles or sub-naming authorities under a naming authority. Details of these operations are described in the following sections.
3.7.1. List Handle(s) under a Naming Authority
3.7.1. List Handle(s) under a Naming Authority
Clients send LIST_HANDLE requests to handle servers to get a list of handles under a naming authority. The Message Header of the LIST_HANDLE request must set its <OpCode> to OC_LIST_HANDLE.
Clients send LIST_HANDLE requests to handle servers to get a list of handles under a naming authority. The Message Header of the LIST_HANDLE request must set its <OpCode> to OC_LIST_HANDLE.
The Message Body of any LIST_HANDLE request is defined as follows:
The Message Body of any LIST_HANDLE request is defined as follows:
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
where
where
<NA_Handle>
A UTF8-String that specifies the naming authority handle.
<NA_Handle> A UTF8-String that specifies the naming authority handle.
To obtain a complete list of the handles, the request must be sent to every handle server listed in one of the service sites of the responsible handle service. Each server within the service site will return its own list of handles under the naming authority. The Message Body of a successful LIST_HANDLE response (from each handle server) is defined as follows:
To obtain a complete list of the handles, the request must be sent to every handle server listed in one of the service sites of the responsible handle service. Each server within the service site will return its own list of handles under the naming authority. The Message Body of a successful LIST_HANDLE response (from each handle server) is defined as follows:
Sun, et al. Informational [Page 40] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun, et al. Informational [Page 40] RFC 3652 Handle System Protocol (v2.1) November 2003
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
リスト_ハンドル応答>の<メッセージボディー:、:= <ヌム_Handles><HandleList>、どこ
<Num_Handles>
Number of handles (managed by the handle server) under the
naming authority.
命名権威の下におけるハンドル(ハンドルサーバで、管理される)の<ヌム_Handles>Number。
<HandleList>
A list of UTF8-Strings, each of which identify a handle
under the naming authority.
UTF8-ストリングの<HandleList>Aリスト。それは命名権威の下でそれぞれハンドルを特定します。
The LIST_HANDLE request may potentially slow down the overall system performance. A handle service (or its service site) has the option of whether or not to support such request. The server will return an RC_OPERATION_DENIED message if LIST_HANDLE is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_HANDLE privilege before fulfilling the request.
HANDLEが要求するLIST_は潜在的に総合体系性能を減速させるかもしれません。 ハンドルサービス(または、サービスサイト)には、そのような要求をサポートするかどうかに関するオプションがあります。 LIST_HANDLEがサポートされないと、サーバはRC_OPERATION_DENIEDメッセージを返すでしょう。 HANDLEが要求するLIST_を受けるサーバは要求を実現させる前のLIST_HANDLE特権をもっている命名権威管理者としてクライアントを認証するべきです。
3.7.2. List Sub-Naming Authorities under a Naming Authority
3.7.2. 命名権威の下におけるリストサブ命名当局
Clients send LIST_NA requests to handle servers to get a list of sub-naming authorities under a naming authority. The Message Header of the LIST_NA request must set its <OpCode> to OC_LIST_NA.
クライアントは命名権威の下でサブ命名当局のリストを得るためにサーバを扱うという要求をLIST_NAに送ります。 NAが要求するLIST_のMessage HeaderはOC_LIST_NAに<OpCode>を設定しなければなりません。
The Message Body of any LIST_NA request is defined as follows:
NAが要求するどんなLIST_のMessage Bodyも以下の通り定義されます:
<Message Body of LIST_HANDLE Request> ::= <NA_Handle>
リスト_ハンドル要求>の<メッセージボディー:、:= <Na_は>を扱います。
where
どこ
<NA_Handle>
A UTF8-String that specifies the naming authority handle.
命名権威ハンドルを指定する<NA_Handle>A UTF8-ストリング。
To obtain a complete list of the sub-naming authorities, the request must be sent to every handle server listed in any one of the service sites of the GHR. Each server within the service site will return its own list of sub-naming authority handles under the given naming authority. The Message Body of a successful LIST_NA response (from each handle server) is defined as follows:
サブ命名当局に関する全リストを得るために、GHRのサービスサイトのいずれにも記載されたあらゆるハンドルサーバに要求を送らなければなりません。 サービスサイトの中の各サーバはそれ自身の権威が与えられた命名権威の下で扱うサブ命名のリストを返すでしょう。 うまくいっているLIST_NA応答(それぞれのハンドルサーバからの)のMessage Bodyは以下の通り定義されます:
Sun, et al. Informational [Page 41] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[41ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
<Message Body of LIST_HANDLE Response> ::= <Num_Handles>
<HandleList>
where
リスト_ハンドル応答>の<メッセージボディー:、:= <ヌム_Handles><HandleList>、どこ
<Num_Handles>
Number of handles (managed by the handle server) under the
naming authority.
命名権威の下におけるハンドル(ハンドルサーバで、管理される)の<ヌム_Handles>Number。
<HandleList>
A list of UTF8-Strings, each of which identifies a sub-
naming authority user-specified naming authority.
UTF8-ストリングの<HandleList>Aリスト。それはそれぞれサブ命名の権威のユーザによって指定された命名権威を特定します。
LIST_NA requests must be sent to servers under the GHR that manages all the naming authority handles. The LIST_NA request may potentially slow down the overall system performance, especially the GHS. A server (or service sites) under the GHR has the option of whether or not to support such requests. The server will return an RC_OPERATION_DENIED message if LIST_NA is not supported. The server that receives a LIST_HANDLE request should authenticate the client as a naming authority administrator with the LIST_NA privilege before fulfilling the request.
権威が扱うすべての命名を管理するGHRの下のサーバにLIST_NA要求を送らなければなりません。 NAが要求するLIST_は潜在的に総合体系性能、特にGHSを減速させるかもしれません。 GHRの下のサーバ(または、サービスサイト)には、そのような要求をサポートするかどうかに関するオプションがあります。 LIST_NAがサポートされないと、サーバはRC_OPERATION_DENIEDメッセージを返すでしょう。 HANDLEが要求するLIST_を受けるサーバは要求を実現させる前のLIST_NA特権をもっている命名権威管理者としてクライアントを認証するべきです。
3.8. Session and Session Management
3.8. セッションとセッション管理
Sessions are used to allow sharing of authentication information or network resources among multiple protocol operations. For example, a naming authority administrator may authenticate itself once through the session setup, and then register multiple handles under the session.
セッションは、複数のプロトコル操作の中で認証情報かネットワーク資源を共有するのを許容するのに使用されます。 例えば、命名権威管理者は、セッションセットアップでそれ自体を一度認証して、次に、セッションで複数のハンドルを登録するかもしれません。
A client may ask the server to establish a session key and use it for subsequent requests. A session key is a secret key that is shared by the client and server. It can be used to authenticate or encrypt any message exchanged under the session. A session is encrypted if every message exchanged within the session is encrypted using the session key.
クライアントは、セッションキーを設立して、その後の要求にそれを使用するようにサーバに頼むかもしれません。 セッションキーはクライアントとサーバによって共有される秘密鍵です。セッションで交換されたどんなメッセージも認証するか、または暗号化するのにそれは使用できます。 セッション中に交換されたあらゆるメッセージがセッションキーを使用することで暗号化されているなら、セッションは暗号化されています。
Sessions may be established as the result of an explicit OC_SESSION_SETUP request from a client. A server may also automatically setup a session when multiple message exchanges are expected to fulfill a request. For example, the server will automatically establish a session if it receives a CREATE_HANDLE request that requires client authentication.
セッションはSESSION_SETUPがクライアントから要求する明白なOC_の結果と書き立てられるかもしれません。 また、複数の交換処理が要求を実現させると予想されるセッションサーバは自動的にセットアップされるかもしれません。 例えば、クライアント認証を必要とするHANDLEが要求するCREATE_を受けると、サーバは自動的にセッションを確立するでしょう。
Every session is identified by a non-zero Session ID that appears in the Message Header. Servers are responsible for generating a unique Session ID for each outstanding session. Each session may have a set of state information associated with it. The state information may
あらゆるセッションがMessage Headerに現れる非ゼロSession IDによって特定されます。 サーバはそれぞれの傑出しているセッションのためにユニークなSession IDを生成するのに原因となります。 各セッションには、それに関連している州の情報のセットがあるかもしれません。 州の情報はそうするかもしれません。
Sun, et al. Informational [Page 42] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[42ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
include the session key and the information obtained from client authentication, as well as any communication options. Servers and clients are responsible for keeping the state information in sync until the session is terminated.
クライアント認証、およびどんなコミュニケーションオプションからも入手されたセッションキーと情報を含めてください。 セッションが終えられるまで状態が同時性で情報であることを保つのにサーバとクライアントは原因となります。
A session may be terminated with an OC_SESSION_TERMINATE request from the client. Servers may also terminate a session that has been idle for a significant amount of time.
セッションはTERMINATEがクライアントから要求するOC_SESSION_で終えられるかもしれません。 また、サーバは重要な時間無駄であるセッションを終えるかもしれません。
3.8.1. Session Setup Request
3.8.1. セッションセットアップ要求
Clients establish a session with a handle server with a SESSION_SETUP request. A SESSION_SETUP request can also be used to update any state information associated to an existing session. The Message Header of the SESSION_SETUP request must have its <OpCode> set to OC_SESSION_SETUP and <ResponseCode> to 0.
クライアントはSETUPが要求するSESSION_でハンドルサーバとのセッションを確立します。 また、既存のセッションまで関連づけられたどんな州の情報もアップデートするのにSETUPが要求するSESSION_を使用できます。 SETUPが要求するSESSION_のMessage Headerには、OC_SESSION_SETUPに用意ができている<OpCode>と<ResponseCode>が0までなければなりません。
The Message Body of any SESSION_SETUP request is defined as follows:
SETUPが要求するどんなSESSION_のMessage Bodyも以下の通り定義されます:
<SESSION_SETUP Request Message Body> ::= <SessionAttributes>
<セッション_セットアップ要求メッセージボディー>:、:= <SessionAttributes>。
where
どこ
<SessionAttributes>
A 4-byte unsigned integer followed by a list of session
attributes. The integer indicates the number of session
attributes in the list. Possible session attributes include
the <HS_SESSION_IDENTITY>, the <HS_SESSION_TIMEOUT>, and the
<HS_SESSION_KEY_EXCHANGE>. Each of these attributes is
defined as follows:
4バイトの符号のない整数がセッション属性のリストを続けた<SessionAttributes>A。 整数はリストのセッション属性の数を示します。 可能なセッション属性は<HS_SESSION_IDENTITY>、<HS_SESSION_TIMEOUT>、および<HS_SESSION_KEY_EXCHANGE>を含んでいます。 それぞれのこれらの属性は以下の通り定義されます:
<HS_SESSION_IDENTITY> ::= <Key>
<Handle>
<ValueIndex>
where
<HS_セッション_のアイデンティティ>:、:= 主要な<の<Handle><ValueIndex>>、どこ
<Key>
A UTF-8 string constant "HS_SESSION_IDENTITY".
<の主要な>A UTF-8は一定の「HS_セッション_のアイデンティティ」を結びます。
<Handle>
<ValueIndex>
A UTF-8 string followed by a 4-byte unsigned
integer that specifies the handle and the handle
value used for client authentication. It must
refer to a handle value that contains the public
key of the client. The public key is used by
the server to authenticate the client.
値がクライアント認証に使用したハンドルとハンドルを指定する4バイトの符号のない整数に従って、UTF-8が結ぶ<ハンドル><ValueIndex>Aは続きました。 それはクライアントの公開鍵を含むハンドル値について言及しなければなりません。 公開鍵はサーバによって使用されて、クライアントを認証します。
Sun, et al. Informational [Page 43] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[43ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
<HS_SESSION_KEY_EXCHANGE> ::= <Key>
<KeyExchangeData>
where
<のHS_セッションの_の主要な_交換>:、:= <の主要な><KeyExchangeData>、どこ
<Key>
A UTF-8 string constant "HS_SESSION_KEY_EXCHANGE".
<の主要な>A UTF-8は一定の「HS_セッションの_の主要な_交換」を結びます。
<KeyExchangeData>
One of the these tuples: <ClientCipher
<ClientCipher KeyExchange>,
<HdlCipher KeyExchange>, or
<ServerCipher KeyExchange>.
Each of these tuples is defined as follows:
<KeyExchangeData>One、これらのtuples: <ClientCipher<ClientCipher KeyExchange>、<HdlCipher KeyExchange>、または<ServerCipher KeyExchange>。 それぞれのこれらのtuplesは以下の通り定義されます:
<ClientCipher KeyExchange> ::= <Key>
<PubKey>
where
<ClientCipher KeyExchange>:、:= <の主要な><PubKey>、どこ
<Key>
A UTF-8 string constant "CLIENT_CIPHER".
<の主要な>A UTF-8は一定の「クライアント_暗号」を結びます。
<PubKey>
A public key provided by the client and used
by the server to encrypt the session key.
クライアントによって提供されて、サーバによって使用される、セッションキーを暗号化する<PubKey>A公開鍵。
<HdlCipher KeyExchange> ::= <Key>
<ExchangeKeyHdl>
<ExchangeKeyIndex>
where
<HdlCipher KeyExchange>:、:= 主要な<の<ExchangeKeyHdl><ExchangeKeyIndex>>、どこ
<Key>
A UTF-8 string constant "HDL_CIPHER".
<の主要な>A UTF-8は一定の「HDL_暗号」を結びます。
<ExchangeKeyHdl>
<ExchangeKeyIndex>
A UTF-8 string followed by a 4-byte unsigned
integer. The <ExchangeKeyHdl> and
<ExchangeKeyIndex> refers to a handle value
used for session key exchange. The handle
value must contain the public key of the
client. The public key will be used by the
server to encrypt the session key before
sending it to the client.
4バイトの符号のない整数に従って、UTF-8が結ぶ<ExchangeKeyHdl><ExchangeKeyIndex>Aは続きました。 セッションの主要な交換にハンドル値に使用されて、>が参照する<ExchangeKeyHdl>と<ExchangeKeyIndex。 ハンドル値はクライアントの公開鍵を含まなければなりません。 公開鍵はサーバによって使用されて、それをクライアントに送る前に主要なセッションを暗号化するでしょう。
<ServerCipher KeyExchange> ::= <Key>
<ServerCipher KeyExchange>:、:= <の主要な>。
where
どこ
Sun, et al. Informational [Page 44] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[44ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
<Key>
A UTF-8 string constant "SERVER_CIPHER". This
tells the server that the client will be
responsible for generating the session key. The
server will have to provide its public key in
the response message and set the <ResponseCode>
to RC_SESSION_EXCHANGEKEY. The client can use
the server's public key to encrypt the session
key and send it to the server via a subsequent
SESSION_EXCHANGEKEY request.
<の主要な>A UTF-8は一定の「サーバ_暗号」を結びます。 これは、クライアントはセッションキーを生成するのに責任があるとサーバに言います。 サーバは、公開鍵を応答メッセージに提供して、RC_SESSION_EXCHANGEKEYに<ResponseCode>を設定しなければならないでしょう。 クライアントは、EXCHANGEKEYが要求するその後のSESSION_を通してセッションキーを暗号化して、それをサーバに送るのにサーバの公開鍵を使用できます。
<DiffieHellman KeyExchange> ::= <Key>
<DHParams>
where
<DiffieHellman KeyExchange>:、:= <の主要な><DHParams>、どこ
<Key>
A UTF-8 string constant "DIFFIE_HELLMAN"
<の主要な>A UTF-8は一定の「ディフィー_ヘルマン」を結びます。
<DHParams>
The values used as input in the Diffie-
Hellman algorithm. It consists of three big
integers of variable length. Each big
integer is encoded in terms of a 4-byte
unsigned integer followed by an octet string.
The octet string contains the big integer
itself. The 4-byte unsigned integer
specifies the number of octets of the octet
string.
値がディフィーヘルマンアルゴリズムで入力されるように使用した<DHParams>。 それは可変長の3つの大きい整数から成ります。 それぞれの大きい整数は八重奏ストリングが支えた4バイトの符号のない整数でコード化されます。 八重奏ストリングは大きい整数自体を含んでいます。 4バイトの符号のない整数は八重奏ストリングの八重奏の数を指定します。
<HS_SESSION_TIMEOUT> ::= <Key>
<TimeOut>
where
<HS_セッション_タイムアウト>:、:= <の主要な><TimeOut>、どこ
<Key>
A UTF-8 string constant "HS_SESSION_TIMEOUT".
<の主要な>A UTF-8は一定の「HS_セッション_タイムアウト」を結びます。
<TimeOut>
A 4-byte unsigned integer that specifies the desired
duration of the session in seconds.
<TimeOut>A、秒にセッションの必要な持続時間を指定する4バイトの符号のない整数。
Note that it should be treated as an error if the same session attribute is listed multiple times in the <SessionAttribute> field. When this happens, the server should return an error message with <ResponseCode> set to RC_PROTOCOL_ERROR.
同じセッション属性が<SessionAttribute>分野に複数の回記載されるならそれが誤りとして扱われるべきであることに注意してください。 これが起こると、サーバは_RC_プロトコルERRORに用意ができている<ResponseCode>があるエラーメッセージを返すべきです。
A SESSION_SETUP_REQUEST can be used to change session attributes of any established session. This happens if the <SessionId> is non-zero
どんな確立したセッションのセッション属性も変えるのにSESSION_SETUP_REQUESTを使用できます。 これは<SessionId>が非ゼロであるなら起こります。
Sun, et al. Informational [Page 45] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[45ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
and matches one of the established sessions. Care must be taken by the server to prevent any unauthorized request from changing the session attributes. For example, an encrypted session may only be changed into an unencrypted session by a SESSION_SETUP_REQUEST with an appropriate MAC in its Message Credential.
そして、確立したセッションのマッチ1。 サーバで注意しなければならなくて、どんな権限のない要求もセッション属性を変えるのを防ぎます。 例えば、暗号化されたセッションはMessage Credentialの適切なMACと共にSESSION_SETUP_REQUESTによって非暗号化されたセッションに変えられるだけであるかもしれません。
3.8.2. Session Setup Response
3.8.2. セッションセットアップ応答
The Message Header of the SESSION_SETUP response must set its <OpCode> to OC_SESSION_SETUP. The <ResponseCode> of the SESSION_SETUP response varies according to the SESSION_SETUP request. It must be set to RC_SUCCESS if the SESSION_SETUP request is successful and the server does not expect a session key to be returned by the client.
SESSION_SETUP応答のMessage HeaderはOC_SESSION_SETUPに<OpCode>を設定しなければなりません。 SETUPが要求するSESSION_によると、SESSION_SETUP応答の<ResponseCode>は異なります。 SETUPが要求するSESSION_がうまくいっていて、サーバがクライアントによって返されるように主要なセッションを予想しないなら、RC_SUCCESSにそれを設定しなければなりません。
The Message Body of the SESSION_SETUP response is empty unless the request is asking for <HS_SESSION_KEY_EXCHANGE>. In this case, the Message Body of the SESSION_SETUP response may contain the encrypted session key from the server, or the server's public key, to be used for session key exchange. The exact format depends on the content of the <HS_SESSION_KEY_EXCHANGE> in the SESSION_SETUP request. If <ClientCipher KeyExchange> or <HdlCipher KeyExchange> is given in the SESSION_SETUP request, the Message Body of the SESSION_SETUP response will contain the encrypted session key from the server and is defined as follows:
要求が<HS_SESSION_KEY_EXCHANGE>を求めていない場合、SESSION_SETUP応答のMessage Bodyは空です。 この場合、SESSION_SETUP応答のMessage Bodyは、セッションの主要な交換に使用されるためにサーバ、またはサーバの公開鍵から主要な暗号化されたセッションを含むかもしれません。 正確な形式はSETUPが要求するSESSION_で<HS_SESSION_KEY_EXCHANGE>の内容に依存します。 SETUPが要求するSESSION_で<ClientCipher KeyExchange>か<HdlCipher KeyExchange>を与えるなら、SESSION_SETUP応答のMessage Bodyをサーバから主要な暗号化されたセッションを含んで、以下の通り定義します:
<Message Body of SESSION_SETUP Response>
::= <RequestDigest>
<EncryptedSessionKey>
[ <EncryptionAlgorithm> ]
where
セッション_セットアップ応答>の<メッセージボディー:、:= <RequestDigest><EncryptedSessionKey>[<EncryptionAlgorithm>]、どこ
<RequestDigest>
Message digest of the SESSION_SETUP request is as specified in
section 2.2.3.
SETUPが要求するSESSION_の<RequestDigest>Messageダイジェストがセクション2.2.3で指定されるようにあります。
<EncryptedSessionKey>
Session key is encrypted using the public key provided in the
SESSION_SETUP request. The session key is a randomly
generated octet string from the server. The server will only
return the <EncryptedSessionKey> if the <KeyExchangeData> in
the SESSION_SETUP request provides the public key from the
client.
<EncryptedSessionKey>Sessionキーは、SETUPが要求するSESSION_に提供された公開鍵を使用することで暗号化されています。 セッションキーはサーバからの手当たりしだいに発生している八重奏ストリングです。SETUPが要求するSESSION_の<KeyExchangeData>がクライアントから公開鍵を提供する場合にだけ、サーバは<EncryptedSessionKey>を返すでしょう。
<EncryptionAlgorithm>
(optional) UTF-8 string that identifies the encryption
algorithm used by the session key.
セッションキーによって使用される暗号化アルゴリズムを特定する(任意)のUTF-8が結ぶ<EncryptionAlgorithm>。
Sun, et al. Informational [Page 46] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[46ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
If <ServerCipher KeyExchange> is given in the SESSION_SETUP request, the server must provide its public key in the SESSION_SETUP response. The public key can be used by the client in a subsequent SESSION_EXCHANGEKEY request (defined below) for session key exchange. In this case, the Message Header of the SESSION_SETUP response must set its <ResponseCode> to RC_SESSION_EXCHANGEKEY. The Message Body of the SESSION_SETUP response must include the server's public key and is defined as follows:
SETUPが要求するSESSION_で<ServerCipher KeyExchange>を与えるなら、サーバはSESSION_SETUP応答に公開鍵を提供しなければなりません。 クライアントはEXCHANGEKEYがセッションの主要な交換のために要求する(以下では、定義されます)その後のSESSION_で公開鍵を使用できます。 この場合、SESSION_SETUP応答のMessage HeaderはRC_SESSION_EXCHANGEKEYに<ResponseCode>を設定しなければなりません。 SESSION_SETUP応答のMessage Bodyはサーバの公開鍵を含まなければならなくて、以下の通り定義されます:
<Message Body of SESSION_SETUP response>
::= <RequestDigest>
<Public Key for Session Key Exchange>
SESSION_SETUP応答>の<メッセージBody:、:= セッションの主要な交換>のための<RequestDigest><公開鍵
where
どこ
<RequestDigest>
Message digest of the SESSION_SETUP request as specified in
section 2.2.3.
SETUPがセクション2.2.3で指定されるように要求するSESSION_の<RequestDigest>Messageダイジェスト。
<Public Key for Session Key Exchange>
Public key from the server to be used for session key
exchange. It is encoded in the same format as the <PublicKey>
record in the HS_SITE value (see section 3.2.2 in [2]).
サーバから主要なSession Key Exchange>Publicがセッションの主要な交換に使用される<の公共のKey。 それはHS_SITE値における<PublicKey>記録と同じ形式でコード化されます。([2])でセクション3.2.2を見てください。
3.8.3. Session Key Exchange
3.8.3. セッションの主要な交換
If the <ResponseCode> of a SESSION_SETUP response is RC_SESSION_EXCHANGEKEY, the client is responsible for generating the session key and sending it to the server. In this case, the client can generate a session key, encrypt it with the public key provided by the server in the SESSION_SETUP response, and send the encrypted session key to the server in a SESSION_EXCHANGEKEY request.
SESSION_SETUP応答の<ResponseCode>がRC_SESSION_EXCHANGEKEYであるなら、クライアントはセッションキーを生成して、それをサーバに送るのに責任があります。この場合、クライアントは、セッションキーを生成して、サーバでSESSION_SETUP応答に公開鍵を提供している状態でそれを暗号化して、EXCHANGEKEYが要求するSESSION_のサーバに主要な暗号化されたセッションを送ることができます。
The Message Header of the SESSION_EXCHANGEKEY request must set its <OpCode> to OC_SESSION_EXCHANGEKEY and its <ResponseCode> to 0. The Message Body of the SESSION_EXCHANGEKEY request is defined as follows:
EXCHANGEKEYが要求するSESSION_のMessage HeaderはOC_SESSION_EXCHANGEKEYへの<OpCode>と0へのその<ResponseCode>を設定しなければなりません。 EXCHANGEKEYが要求するSESSION_のMessage Bodyは以下の通り定義されます:
<Message Body of OC_SESSION_EXCHANGEKEY>
::= <Encrypted Session Key>
[ <EncryptionAlgorithm> ]
OC_セッション_EXCHANGEKEY>の<メッセージボディー:、:= <はセッションの主要な>を暗号化しました。[<EncryptionAlgorithm>]
where
どこ
<EncryptedSessionKey>
Session key encrypted using the public key provided in the
SESSION_SETUP response. The session key is a randomly
generated octet string by the client.
公開鍵を使用することで暗号化された<EncryptedSessionKey>SessionキーはSESSION_SETUP応答に提供されました。 セッションキーはクライアントによる手当たりしだいに発生している八重奏ストリングです。
Sun, et al. Informational [Page 47] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[47ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
<EncryptionAlgorithm>
(optional) UTF-8 string that identifies the encryption
algorithm used by the session key.
セッションキーによって使用される暗号化アルゴリズムを特定する(任意)のUTF-8が結ぶ<EncryptionAlgorithm>。
During the session key exchange, the server receiving the exchange key or session key has the responsibility of ensuring that the key meets the security requirements defined in its local policy. If the server considers the key being volunable, it must return an error message to the client with <ResponseCode> set to RC_SESSION_KEY_INVALID.
セッションの主要な交換の間、交換キーかセッションキーを受けるサーバはキーがローカルの方針で定義されたセキュリティ必要条件を満たすのを確実にする責任を持っています。 サーバがvolunableであるキーを考えるなら、それはRC_SESSION_KEY_INVALIDに用意ができている<ResponseCode>をもっているクライアントにエラーメッセージを返さなければなりません。
3.8.4. Session Termination
3.8.4. セッション終了
Clients can terminate a session with a SESSION_TERMINATE request. The Message Header of a SESSION_TERMINATE request must have its <OpCode> set to OC_SESSION_TERMINATE and its <ResponseCode> to 0. The message body of any SESSION_TERMINATE request must be empty.
クライアントはTERMINATEが要求するSESSION_とのセッションを終えることができます。 TERMINATEが要求するSESSION_のMessage Headerは<OpCode>に_SESSION_TERMINATEとその<ResponseCode>を0までOCに設定させなければなりません。 TERMINATEが要求するどんなSESSION_のメッセージボディーも空であるに違いありません。
The server must send a SESSION_TERMINATE response to the client after the session is terminated. The server should only terminate the session after it has finished processing all the requests (under the session) that were submitted before the Session Termination request.
セッションが終えられた後にサーバはSESSION_TERMINATE応答をクライアントに送らなければなりません。 サーバはSession Termination要求の前に提出されたすべての要求(セッションでの)を処理し終えた後にセッションのときに終わるだけであるべきです。
The message header of the SESSION_TERMINATE response must set its <OpCode> to OC_SESSION_TERMINATE. A successful SESSION_TERMINATE response must have its <ResponseCode> set to RC_SUCCESS, and an empty message body.
SESSION_TERMINATE応答のメッセージヘッダーはOC_SESSION_TERMINATEに<OpCode>を設定しなければなりません。 うまくいっているSESSION_TERMINATE応答で、RC_SUCCESS、および空のメッセージ本体に<ResponseCode>を用意ができさせなければなりません。
4. Implementation Guidelines
4. 実施要綱
4.1. Server Implementation
4.1. サーバ実装
The optimal structure for any handle server will depend on the host operating system. This section only addresses those implementation considerations that are common to most handle servers.
どんなハンドルサーバのための最適の構造もホスト・オペレーティング・システムに依存するでしょう。 このセクションはそれらのほとんどのハンドルサーバに共通の実装問題を扱うだけです。
A good server implementation should allow easy configuration or fine-tuning. A suggested list of configurable items includes the server's network interface(s) (e.g., IP address, port number, etc.), the number of concurrent processes/threads allowed, time-out intervals for any TCP connection and/or authentication process, re- try policy under UDP connection, policies on whether to support recursive service, case-sensitivity for ASCII characters, and different levels of transaction logging, etc.
良いサーバ実装は簡単な構成か微調整を許容するべきです。 構成可能な項目の提案されたリストはサーバのネットワーク・インターフェース(例えば、IPアドレス、ポートナンバーなど)を含んで、許容された並行処理/スレッドの数(どんなTCP接続、そして/または、認証過程のためのタイムアウト間隔も)はUDP接続、再帰的なサービスをサポートするかどうかに関する方針、ASCII文字のためのケース感度、および異なったレベルのトランザクション伐採などの下で方針を再試みます。
Sun, et al. Informational [Page 48] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[48ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
All handle server implementations must support all the handle data types as defined in the "Handle System Namespace and Service Definition" [2]. They should also be able to store handle values of any application defined data type.
すべてのハンドルサーバ実装が「ハンドルシステム名前空間とサービス定義」[2]で定義されるようにすべてのハンドルデータ型をサポートしなければなりません。 また、彼らはどんなアプリケーションの定義されたデータ型のハンドル値も保存できるべきです。
A handle server must support multiple concurrent activities, whether they are implemented as separate processes or threads in the host's operating system, or multiplexed inside a single name server program. A handle server should not block the service of UDP requests while it waits for TCP data or other query activities. Similarly, a handle server should not attempt to provide recursive service without processing such requests in parallel, though it may choose to serialize requests from a single client, or to regard identical requests from the same client as duplicates.
ハンドルサーバは複数の同時発生の活動をサポートしなければなりません、それらを別々のプロセスかスレッドとしてホストのオペレーティングシステムで実装するか、または単一のネームサーバプログラムの中で多重送信することにかかわらず。 TCPデータか他の質問活動を待っている間、ハンドルサーバはUDP要求のサービスを妨げるべきではありません。 同様に、ハンドルサーバは、平行なそのような要求を処理しないで再帰的なサービスを提供するのを試みるべきではありません、独身のクライアントからの要求を連載するか、または写しと同じクライアントからの同じ要求を見なすのを選ぶかもしれませんが。
4.2. Client Implementation
4.2. クライアント実装
Clients should be prepared to receive handle values of any data type. Clients may choose to implement a callback interface to allow new modules or plug-ins to be added to support any application-defined data types.
クライアントはどんなデータ型のハンドル値も受ける用意ができているべきです。 クライアントは、新しいモジュールかプラグインがどんなアプリケーションで定義されたデータ型もサポートするために加えられるのを許容するためにコールバックインタフェースを実装するのを選ぶかもしれません。
Clients that follow service referrals or handle aliases must avoid falling into an infinite loop. They should not repeatedly contact the same server for the same request with the same target entry. A client may choose to use a counter that is incremented each time it follows a service referral or handle alias. There should be a configurable upper limit to the counter to control the levels of service referrals or handle aliases followed by the client.
サービス紹介の後をつけるか、または別名を扱うクライアントは、無限ループになるのを避けなければなりません。 彼らは同じ要求のために同じ目標エントリーで繰り返して同じサーバに連絡するべきではありません。 クライアントは、サービス紹介かハンドル別名に従うたびに増加しているカウンタを使用するのを選ぶかもしれません。 サービス紹介のレベルを制御するか、またはクライアントによって従われた別名を扱うカウンタへの構成可能な上限があるべきです。
Clients that provide some caching can expect much better performance than those that do not. Client implementations should always consider caching the service information associated with a naming authority. This will reduce the number of roundtrips for subsequent handle requests under the same naming authority.
いくつかのキャッシュを提供するクライアントはそうしないそれらよりはるかに良い性能を予想できます。 クライアント実装は、いつも命名権威に関連しているサービス情報をキャッシュすると考えるべきです。 これは、権威を命名しながら、同じくらい下のその後のハンドル要求のための往復旅行の数を減少させるでしょう。
5. Security Considerations
5. セキュリティ問題
The overall Handle System security considerations are discussed in "Handle System Overview" [1]; that discussion applies equally to this document. Security considerations regarding the Handle System data model and service model are discussed in "Handle System Namespace and Service Definition" [2].
「ハンドルシステム概要」[1]で総合的なHandle Systemセキュリティ問題について議論します。 その議論は等しくこのドキュメントに適用されます。 「ハンドルシステム名前空間とサービス定義」[2]でHandle Systemデータモデルとサービスモデルに関するセキュリティ問題について議論します。
Sun, et al. Informational [Page 49] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[49ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
For efficiency, the Handle protocol includes a simple challenge- response authentication protocol for basic client authentication. Handle servers are free to provide additional authentication mechanisms (e.g., SASL) as needed. Details of this will be discussed in a separate document.
効率のために、Handleプロトコルは基本的なクライアント認証のための簡単な挑戦応答認証プロトコルを含んでいます。 ハンドルサーバは必要に応じて、無料で、追加認証機構(例えば、SASL)を提供できます。 別々のドキュメントでこの詳細について議論するでしょう。
Data integrity under the Handle protocol is achieved via the server's digital signature. Care must be taken to protect the server's private key from any impersonation attack. Any change to the server's public key pair must be registered (in terms of service information) with the GHR.
Handleプロトコルの下におけるデータの保全はサーバのデジタル署名で達成されます。 どんなものまね攻撃からもサーバの秘密鍵を保護するために注意しなければなりません。 サーバの公開鍵組へのどんな変化もGHRに登録しなければなりません(サービス情報に関して)。
6. Acknowledgements
6. 承認
This work is derived from the earlier versions of the Handle System implementation. The overall digital object architecture, including the Handle System, was described in a paper by Robert Kahn and Robert Wilensky [22] in 1995. Development continued at CNRI as part of the Computer Science Technical Reports (CSTR) project, funded by the Defense Advanced Projects Agency (DARPA) under Grant Number MDA-972- 92-J-1029 and MDA-972-99-1-0018. Design ideas are based on those discussed within the Handle System development team, including David Ely, Charles Orth, Allison Yu, Sean Reilly, Jane Euler, Catherine Rey, Stephanie Nguyen, Jason Petrone, and Helen She. Their contributions to this work are gratefully acknowledged.
Handle System実装の以前のバージョンからこの仕事を得ます。 Handle Systemを含む総合的なデジタル目的アーキテクチャは1995年に論文でロバート・カーンとロバート・ウィレンスキー[22]によって説明されました。 開発はグラントNumber MDA-972- 92-J-1029とMDA-972-99-1-0018の下でDefense Advanced Projects Agency(DARPA)によって資金を供給されたコンピュータScience Technical Reports(CSTR)プロジェクトの一部としてCNRIで続きました。 デザイン考えはHandle System開発チームの中で議論したものに基づいています、デヴィッド・イーリー、シャルル・オルト、アリソン・ユー、ショーン・ライリー、ジェーン・オイラー、キャサリン・レイ、ステファニーNguyen、ジェイソンPetrone、およびヘレンSheを含んでいて。 この仕事への彼らの貢献は感謝して承諾されます。
The authors also thank Russ Housley (housley@vigilsec.com), Ted Hardie (hardie@qualcomm.com), and Mark Baugher (mbaugher@cisco.com) for their extensive review and comments, as well as recommendations received from other members of the IETF/IRTF community.
また、作者は彼らの大量のレビューとコメントについてラスHousley( housley@vigilsec.com )、テッド・ハーディー( hardie@qualcomm.com )、およびマークBaugher( mbaugher@cisco.com )に感謝します、IETF/IRTF共同体の他のメンバーから受けられた推薦と同様に。
7. Informative References
7. 有益な参照
[1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650,
November 2003.
[1] S.とL.Lannom、「ハンドルシステム概要」、RFC3650、2003年11月Sun。
[2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace and
Service Definition", RFC 3651, November 2003.
[2] Sun、S.、ライリー、S.、およびL.Lannomが「システム名前空間とサービス定義を扱う」、RFC3651、11月2003日
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[3]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[4] A. Freier, P. Karlton, P. Kocher "The SSL Protocol Version 3.0"
[4] A.フライア、P.Karlton、「SSLはバージョン3インチ議定書の中で述べる」P.コッハー
[5] RSA Laboratories, "Public-Key Cryptography Standard PKCS#7"
http://www.rsasecurity.com/rsalabs/pkcs/
[5]RSA研究所、「公開鍵暗号化標準PKCS#の7インチの http://www.rsasecurity.com/rsalabs/pkcs/ 」
Sun, et al. Informational [Page 50] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[50ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
[6] U.S. Federal Information Processing Standard: Digital Signature
Standard.
[6] 米国連邦情報処理基準: デジタル署名基準。
[7] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002.
[7]Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム」、RFC3370、2002年8月。
[8] Braden, R., "FTP Data Compression", RFC 468, March 1973.
[8] ブレーデン、R.、「FTPデータ圧縮」、RFC468、1973年3月。
[9] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[9] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[10] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[10]NIST、FIPSパブ180-1: ハッシュ規格、1995年4月を確保してください。
[11] D. Cohen, "On Holy Wars and a Plea for Peace", Internet
Experiment, Note IEN 137, 1 April 1980.
[11] D.コーエンと、「平和のための聖戦と請願」(インターネット実験)はIEN137、1980年4月1日に注意します。
[12] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC
3124, June 2001.
[12]BalakrishnanとH.とS.Seshan、「混雑マネージャ」(RFC3124)2001年6月。
[13] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[13] R.カーン、R.ウィレンスキー、「分配されたデジタルオブジェクトサービスのためのフレームワーク、1995年5月、 http://www.cnri.reston.va.us/k-w.html 」
[14] Polk, W., Housley, R. and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.
[14]ポーク、W.、Housley、R.、およびL.Bassham、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
[15] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[15]HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。
[16] M. Bellare and P. Rogaway. The Exact Security of Digital
Signatures - How to Sign with RSA and Rabin. In Advances in
Cryptology-Eurocrypt '96, pp.399-416, Springer-Verlag, 1996.
[16] M.BellareとP.Rogaway。 デジタル署名の正確なセキュリティ--RSAとラビンと契約する方法。 Cryptology-Eurocrypt96年、pp.399-416、Springer-Verlag、1996のAdvancesで。
[17] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[17]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[18] R. Kahn, R. Wilensky, "A Framework for Distributed Digital
Object Services, May 1995, http://www.cnri.reston.va.us/k-w.html
[18] R.カーン、R.ウィレンスキー、「分配されたデジタル物のサービスのための枠組み、1995年5月、 http://www.cnri.reston.va.us/k-w.html 」
Sun, et al. Informational [Page 51] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[51ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
8. Authors' Addresses
8. 作者のアドレス
Sam X. Sun Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのサムX.Sun社
Phone: 703-262-5316 EMail: ssun@cnri.reston.va.us
以下に電話をしてください。 703-262-5316 メールしてください: ssun@cnri.reston.va.us
Sean Reilly Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのショーンライリー社
Phone: 703-620-8990 EMail: sreilly@cnri.reston.va.us
以下に電話をしてください。 703-620-8990 メールしてください: sreilly@cnri.reston.va.us
Larry Lannom Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのラリーLannom社
Phone: 703-262-5307 EMail: llannom@cnri.reston.va.us
以下に電話をしてください。 703-262-5307 メールしてください: llannom@cnri.reston.va.us
Jason Petrone Corporation for National Research Initiatives (CNRI) 1895 Preston White Dr., Suite 100 Reston, VA 20191
国家の研究イニシアチブ(CNRI)1895プレストンホワイト博士、100レストン、Suiteヴァージニア 20191へのジェイソンPetrone社
Phone: 703-262-5340 EMail: jpetrone@cnri.reston.va.us
以下に電話をしてください。 703-262-5340 メールしてください: jpetrone@cnri.reston.va.us
Sun, et al. Informational [Page 52] RFC 3652 Handle System Protocol (v2.1) November 2003
Sun、他 情報[52ページ]のRFC3652は2003年11月にシステムプロトコル(v2.1)を扱います。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Sun, et al. Informational [Page 53]
Sun、他 情報[53ページ]
一覧
スポンサーリンク
