=================================================================== RCS file: /home/cvs/OpenXM/doc/OpenXM-specs/OX-RFC-103.oxw,v retrieving revision 1.1 retrieving revision 1.5 diff -u -p -r1.1 -r1.5 --- OpenXM/doc/OpenXM-specs/OX-RFC-103.oxw 2003/12/08 23:26:03 1.1 +++ OpenXM/doc/OpenXM-specs/OX-RFC-103.oxw 2004/09/19 12:17:40 1.5 @@ -1,38 +1,368 @@ -% $OpenXM$ -%% OXWEAVE=${OpenXM_HOME}/bin/oxweave --recursive --plain -%% ${OXWEAVE} C ja >oxshell-ja.tex -//&ja \documentclass{jarticle} -//&en \documentclass{article} +% $OpenXM: OpenXM/doc/OpenXM-specs/OX-RFC-103.oxw,v 1.4 2004/09/18 11:40:16 takayama Exp $ +/*&C -//&ja \title{OpenXM RFC 103 draft (RFC 100 追加)} -//&en \title{OpenXM RFC 103 draft (RFC 100 supplement} -//&C \author{OpenXM Committers} -//&C \date{December 9, 2004} -//&C \newtheorem{example}{Example} -\usepackage{html} +OX-RFC: 103 OpenXM committers + + December 9, 2003, + September 19, 2004 -\begin{document} -\maketitle +*/ +//&en Supplement to OX-RFC-100 +//&en --- Broadcasting in process trees and engine authentication +//&ja OX-RFC-100 への追加機能 +//&ja --- プロセス木構造での同報とエンジン認証 +/*&C + +Status of this memo + This is an experimental specification. + Distribution of this memo is unlimited. + +Copyright Notice + OpenXM.org, 2003, 2004 + +*/ + + /*&ja + +@@要約 この RFC は OpenXM RFC 100 (および 101) の実装により明らかになった種々の問題点をもとに RFC 100 プロトコルへの幾つかの追加を提案する. + */ -//&ja \section{中断の伝播} -//&en \section{Propagation of an interruption} +//&ja @@中断および変数の伝播 +//&en @@Propagation of an interruption and a value of a variable +//&ja @@@中断 +//&en @@@Interruption -//&ja \section{新しい CMO} -//&en \section{New CMO} +/*&ja -//&ja \section{ファイルへの読み書き} -//&en \section{File IO} +OX RFC 103 では, +エンジンは OX RFC 100 に定義された中断処理を完了したのち, +さらに次の処理をおこなわないといけない. +上意下達の中断処理: +1. 自分の子供プロセスをすべてリストする + (たとえば asir の場合は ox_get_serverinfo()) +2. 子供プロセスに順番に OpenXM-RFC 100 の中断メッセージを送る. -//&ja \section{エンジン認証手続き} -//&en \section{Engine authentication} +*/ -//&ja \section{貢献者} -//&en \section{Contributors} +/*&en -\end{document} +Engines complient to OX RFC 103 must execute the following +procedures after finishing the interruption exception +defined by OX RFC 100. + +1. List all the child processes. + (For example, use the function ox_get_serverinfo() in case of asir). +2. Send all the child processes the interruption message defined + OX RFC 100. + +*/ + +//&ja @@@サーバ木の大域変数 +//&en @@@Global variable of the tree of the servers + +//&ja OX RFC 103 対応のエンジンはエンジン関数 +/*&en +The engines complient to OX RFC 103 implement the engine function +*/ +/*&C + ox103_set_shared_variable(CMO string Name, CMO object value) +*/ +/*&ja +を実装している. +この関数が呼ばれると, エンジンスタックマシンの変数 Name に値 value +が設定され, さらに子どものプロセスすべてのエンジン関数 + ox103_set_shared_variable +をよぶ. +*/ +/*&en +When this function is called, +the value value is assigned to +the variable Name of the engine stackmachine +and the engine calls the function + ox103_set_shared_variable +of all the child processes with the same arguments. +*/ + +/*&ja +たとえば, +この機能は asir-contrib において変数 Xm_noX (ox server 用の debug +window を表示するかしないかのフラグ) の値を同報するのに用いている. +*/ +/*&en +For example, +this protocol is used in the asir-contrib +to broad cast the value of the variable Xm\_noX, +which is the flag of hiding the debug window of an ox server. +*/ + + +//&ja @@新しい CMO +//&en @@New CMO + +//&ja @@ファイルへの読み書き +//&en @@File IO + +//&ja @@エンジン認証手続き +//&en @@Engine authentication + +/*&ja + +バイトオーダーを決めるための情報交換 (OX-RFC 100 参照) の前に +エンジン認証手続きをおこなう. + +認証プロトコルには下の図の step 1, step 2, step 3 である. + + + client server + + ---------------- step 1 -----------------------> + ssh による server への login. + controle server, engine server との接続を確立するための + ポート番号および -control= ... , -data=... + 認証方法および -authtype=NONE | <> + 認証パスワード -passControl=... , -passData=... + も送信される. + 認証パスワードの暗号 -authEncoding=<> | file | RSA + 化方法の指定. + << >> は src/kxx/ox の標準値 + + + <---------------- step 2 --------------------------> + -reverse の場合は <--- の向きに TCP/IP 接続が確立される. + そうでないときは ---> の向きに TCP/IP 接続が確立される. + + <---------------- step 3 --------------------------> + -authtype=oneTimePassword の時. + connect した側が accept した側へ oneTimePassword を送る. + 末尾の 0 を送信する. + + 以下 launcher の仕事は終了して, engine と control に制御が移る. + <---------------- step 4 --------------------------> + engine の byte order を設定. + + <----------------------------------------------------> + OpenXM のパケット交換 + + +*/ + +/*&ja + + authtype は NONE か oneTimePassword である. + oneTimePassword は英数字で構成された列である. + oneTimePassword は常にクライアントで生成されて, なんらかの方法でサーバに + 配送される. connect 側が oneTimePassword を平文で accept 側に送信して + 認証が終了する. + + authEncoding で oneTimePassword の配送方法を規定する. + authEncoding は NONE か file か RSA である. + + authEncoding=NONE が選択された場合 oneTimePassword の配送に特別な方法を利用 + しない. + NONE を選択した場合, 現在の ox launcher の実装ではたとえば -passControl + のあとに oneTimePassword が生の形で現れることとなる. + Unix の場合これは command の引数であり client と server の通信路が + ssh 等で暗号化されていたとするとネットワークユーザは覗きみることはできないが, + 同一機のユーザは見ることが可能である. + したがって NONE の選択が可能であるのは client および server が十分信頼 + できるときに限る. + +*/ + +/*&ja + +@@@authEncoding=file の場合. + + authEncoding=file を選択した場合は oneTimePassword は別に用意された安全な + 通信経路(たとえば scp) を用いて file として配送される. + oneTimePassword が格納された file 名を -passControl, -passData 引数で渡す. + file 名は $HOME/.openxm/tmp.otp/ からの相対パス名である. + パスの区切り文字は windows でも / を用いる. + クライアントは次の規則でファイル名を生成する. + ファイル名には英数字と . - _ の利用しかゆるされない. ファイル名は次の形式 + である. + + clientname-servernameUidPidSerial-time.pass + + ここで time は time(2) の戻り値を数字文字列に変換した形式である. + oneTimePassword の生成時刻を切り上げて 10 分毎の正時に変換したものとする. + servernameUidPidSerial は client が oneTimePassword を生成してから + 10 分間, クライアントシステムで高い確率で一意的であることが保証されている + 文字列ならなんでもよい. + + 例 + client server + + oneTimePassword 1342546 を格納したファイル + yama.openxm.org-00001-2312123123.pass を生成 + + oneTimePassword 89123888 を格納したファイル + yama.openxm.org-00002-2312123124.pass を生成 + -----------------------------------------------------> + 上の二つのファイルを安全な通信路を用いて配送する. + (たとえば scp ) + + -----------------------------------------------------> + ox -authtype oneTimePassword + -authEncoding file + -passControl yama.openxm.org-00001-2312123123.pass + -passData yama.openxm.org-00002-2312123124.pass + + + <---------------- step 2 --------------------------> + -reverse の場合は <--- の向きに TCP/IP 接続が確立される. + そうでないときは ---> の向きに TCP/IP 接続が確立される. + + <---------------- step 3 --------------------------> + connect した側が accept した側へ oneTimePassword を平文でおくる. + + + + oneTimePassword 1342546 を格納したファイル + yama.openxm.org-00001-2312123123.pass を server に生成するために + たとえば sendStringAsAfile(char *servername, char *serveruser, + char *filename, char *otp); + のような API を用意しておくとよいであろう. + +*/ + +/*&ja + +@@@authEncoding=RSA の場合. + +RSA の秘密鍵, 公開鍵を格納するファイル名は以下のとおり. +$HOME/.openxm/rsa/ox103-rsa0-identity (秘密鍵をならべたもの) +$HOME/.openxm/rsa/ox103-rsa0-identity.pub (公開鍵: この形式では利用されず) +$HOME/.openxm/rsa/ox103-rsa0-authorizedkeys (公開鍵をならべたもの) + +鍵ファイルは次のデータを空白で区切って並べたものである. + user識別子 鍵(１０進数字列) RSAフォーマット識別子(optional) +コメント行は # で始まる. +各データの区切りは 0xd または 0xa または 両方である. + +フォーマット識別子が 0 の場合は公開鍵暗号化 +x --> x^65537 mod n を用い, 128 byte (1024 bit) づつデータを区切って処理する. +秘密鍵暗号化は x --> x^d mod n を用いる. +フォーマット識別子 0 は実験用の意味. +秘密鍵は n,d , 公開鍵は n の形式で n と d は , で区切る. +文字列を送信するときは 0 が文字列終りのマークとなり, +0 でのこり部分を埋める. バイト列を送るときはデータの長さは別送する. + +Todo: 鍵の格納方法, データ区切りの方法など可能な限り +RFC3447 に準拠するように変更せよ. 準拠が完了したら -rsa0- を +-rsa- と変更する. + +例: + +client 側 + + ox103-rsa0-identity + # client 側が使う秘密鍵 + takayama@client.math.kobe-u.ac.jp 1234523.... + + + ox103-rsa0-authorizedkeys + @ server 側が使う秘密鍵に対応する公開鍵 + takayama@server.math.kobe-u.ac.jp 8989898.... + +server 側 + ox103-rsa0-identity + # server 側が使う秘密鍵 + takayama@server.math.kobe-u.ac.jp 8781234.... + + ox103-rsa0-authorizedkeys + @ client 側が使う秘密鍵に対応する公開鍵 + takayama@client.math.kobe-u.ac.jp 89891.... + +authEncoding=RSA を利用する場合はこれらの鍵を適切に .openxm/rsa の下に +置かないといけない. .openxm/rsa の permission は rwx------ であること. + +注意: 秘密鍵を生で格納しない場合ファイル名を ox103-rsa2-* 等と変更する +予定. RSA encoding 方法は数字無し, 数字の大きいものから鍵ファイルを +順番にサーチして RSA のフォーマットを決定する. + +authEncoding=RSA の場合 -passData および -passControl は +oneTimePassword (文字列) を bit data とみて rsa で暗号化したものを +URL encoding した形で送る. + +oneTimePassword の周期は十分大きくないといけない. +一年は 31536000 秒である. 100 年は 3153600000 秒 (10 桁) である. +oneTimePassword は数字の場合 10 桁以上であることが必須であり, +20 桁以上であることが望ましい. + +*/ + +/*&ja + +@@@Step 1 が失敗した場合について. + +Step 1 の失敗の原因には次のような可能性がある. +1. ssh による remote login の失敗. +2. Remote server のパスに ox100start/ox 等のローンチャが存在しない. +3. Remote server に xterm が存在しないか, 存在しても X サーバの接続に失敗する. +4. Remote server にエンジンが存在しない. +5. Remote server と client の TCP/IP 接続がなんらかの原因で失敗する. + +失敗の場合に対応するため, +TCP/IP 接続での Accept 側はタイムアウト動作をすること. + + +失敗の原因を知らせるプロトコルはきめられていないが, +実装上の対策として以下のものがある. +1. エラーメッセージを出力して sleep(10); する. +2. エラーメッセージをファイル等に出力する. + +なお OX-RFC-101 では Step 1 が分離しているため, エラーの通知がより簡単である. + +*/ + + +//&ja @@貢献者および試験実装 +//&en @@Contributors and sample implementations + +/*&ja +中断および変数の伝播については高山が設計, asir および kan/sm1 への +実装, 評価をおこなった. +(OpenXM/src/asir-contrib/packages/src/oxrfc103.rr, + OpenXM/src/kan96xx/Doc/oxrfc103.sm1 + をみよ). + +エンジン認証手続きの file encoding 法は野呂と高山の議論から生まれた. +エンジン認証手続きは ox100start, ox に部分実装されている. + OpenXM/src/kxx/ +のファイル群および + OpenXM/src/kan96xx/Doc/ox.sm1 +をみよ. +例: sm1を起動後, (ox.sm1) run asirconnectr +*/ + +/*&ja +行列, ベクトルの CMO は NTL のサーバ化をテストケースとして +岩根が設計, 実装, 評価を行った. +RSA のキー生成, DES 等の OpenXM crypt ライブラリの実装は岩根がおこなっている. +OpenXM/src/ox_ntl/crypt をみよ. +*/ + +//&ja @@参考文献 +//&en @@Bibliography + +/*&C + +[OpenXM-RFC-100] Design and Implementation of OpenXM Client-Server Model + and Common Mathematical Object Format. M.Noro, N.Takayama + +[OpenXM-RFC-101] Protocol to Start Engines. K.Ohara + + +[RFC3447] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography + Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003. + (Format: TXT=143173 bytes) (Obsoletes RFC2437) (Status: + INFORMATIONAL) + +*/