% $OpenXM: OpenXM/doc/OpenXM-specs/OX-RFC-103.oxw,v 1.5 2004/09/19 12:17:40 takayama Exp $ OX-RFC: 103 OpenXM committers December 9, 2003, September 19, 2004 February 1, 2006 OX-RFC-100 への追加機能 --- プロセス木構造での同報とエンジン認証 --- エラーパケットの構造. Status of this memo This is an experimental specification. Distribution of this memo is unlimited. Copyright Notice OpenXM.org, 2003, 2004, 2006 @@要約 この RFC は OpenXM RFC 100 (および 101) の実装により明らかになった種々の問題点をもとに RFC 100 プロトコルへの幾つかの追加を提案する. @@中断および変数の伝播 @@@中断 OX RFC 103 では, エンジンは OX RFC 100 に定義された中断処理を完了したのち, さらに次の処理をおこなわないといけない. 上意下達の中断処理: 1. 自分の子供プロセスをすべてリストする (たとえば asir の場合は ox_get_serverinfo()) 2. 子供プロセスに順番に OpenXM-RFC 100 の中断メッセージを送る. @@@サーバ木の大域変数 OX RFC 103 対応のエンジンはエンジン関数 ox103_set_shared_variable(CMO string Name, CMO object value) を実装している. この関数が呼ばれると, エンジンスタックマシンの変数 Name に値 value が設定され, さらに子どものプロセスすべてのエンジン関数 ox103_set_shared_variable をよぶ. たとえば, この機能は asir-contrib において変数 Xm_noX (ox server 用の debug window を表示するかしないかのフラグ) の値を同報するのに用いている. @@新しい CMO @@ファイルへの読み書き @@エンジン認証手続き バイトオーダーを決めるための情報交換 (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 のパケット交換 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 が十分信頼 できるときに限る. @@@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 を用意しておくとよいであろう. @@@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 桁以上であることが望ましい. @@@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 が分離しているため, エラーの通知がより簡単である. @@貢献者および試験実装 中断および変数の伝播については高山が設計, 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 行列, ベクトルの CMO は NTL のサーバ化をテストケースとして 岩根が設計, 実装, 評価を行った. RSA のキー生成, DES 等の OpenXM crypt ライブラリの実装は岩根がおこなっている. OpenXM/src/ox_ntl/crypt をみよ. @@エラーパケットの構造. Error packet は CMO_ARRAY を body 部分とする CMO であるが, ここではその body 部分の array の構造を定義する. 0 番目の成分は CMO_INT32 である. 意味はサーバ依存. 1 番目の成分は CMO_INT32 である. 意味はサーバ依存. 2 番目の成分は CMO_STRING でありエラーメッセージを格納する. 3 番目の成分(optional) が ox-rfc-103 で新しく定義する部分である. 3 番目の成分のデータ型は CMO_ARRAY である. Array の各要素はまた長さ 2 の CMO_ARRAY であり, 第一成分が CMO_STRING, 第2成分は CMO オブジェクトである. 第一成分はキーワードが格納され, 第2成分はその値である. キーワードとして現在次のものを ox-rfc-103 として提案している. なおサーバは全てのキーワードの値を戻す必要はない. reason_of_error, (CMO_STRING)実行時エラーの理由 where, (CMO_ARRAY) 実行時エラーの場所をあらわす CMO_STRING のarray. line, (CMO_ARRAY) 実行時エラーを起こした行番号(CMO_INT32) のarray. locals, (CMO_ARRAY) 実行時エラーの時の局所変数の名前と値の pair(長さ2のarray) の array parse_error_at, (CMO_INT32) parse エラーをおこした行番号. reason_of_parse_error, (CMO_STRING) parse エラーの理由. Example 1. [["parse_error_at", 3 ], ["reason_of_parse_error","parse error after (x-)"], ] Example 2. [["reason_of_error", "invalid argument"], ["where",["shell","length"]], ["line", 15] ] @@参考文献 [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)