.\"
.\" %FreeBSD: src/usr.sbin/ntp/doc/ntp.keys.5,v 1.1 2000/01/13 09:59:44 sheldonh Exp %
.\"
.Dd January 13, 2000
.\" jpman %Id: ntp.keys.5,v 1.4 2000/06/02 11:03:21 takamune Stab %
.\" WORD: key file		鍵ファイル
.\" WORD: key number		鍵番号
.Dt NTP.KEYS 5
.Os
.Sh 名称
.Nm ntp.keys
.Nd NTP デーモンの鍵ファイルフォーマット
.Sh 書式
.Nm /etc/ntp.keys
.Sh 解説
以下は NTP 鍵ファイルの形式の解説です。
これらのファイルの使用に関する解説は、
.Xr ntp.conf 5
マニュアルページの
.Qq 認証サポート
節を参照してください。
.Pp
DES の場合、
鍵は 56 ビット長で、型によっては各バイトにパリティがつきます。MD5
の場合、鍵は 64 ビット (8 バイト) です。
.Xr ntpd 8
は、
コマンドラインオプション
.Fl k
もしくは設定ファイル中の
.Ar keys
文を使用して指定されるファイルから鍵を読み込みます。鍵番号 0 は NTP
標準によって (56 ビットの 0 として) 決定されており変更できませんが、
1 から 15 の鍵番号の内の 1 つ以上が鍵ファイル中で任意に
セットできます。
.Pp
鍵ファイルは、設定ファイルと同様のコメント記述法
を使用しています。鍵のエントリは
.Pp
.Dl keyno type key
.Pp
の形式の固定されたフォーマットを使用します。ここで、
.Ar keyno
は正の整数、
.Ar type
は鍵の形式を定義する単一文字、
.Ar key
は鍵それ自身です。
.Pp
.Ar key
は、
.Ar type
文字による制御で、3 つの異なるフォーマットの
内の 1 つで与えられます。3 つの鍵の型とそれに対応するフォーマットは、
次にあげるとおりです。
.Bl -tag -width indent
.It S
.Ar key
は、 DES 仕様に定められたフォーマットの 64-ビットの
16 進数で、各オクテットの上位 7 ビットが使用された 56-ビット
鍵です。各オクテットの下位 1 ビットは、オクテットを奇数パリティに
保つように与えられます。先頭の 0 は省略できません (すなわち、鍵は
正確に 16 桁の 16 進数である必要があります)。また、奇数パリティが保
たれねばなりません。それゆえ、0
.Ar key
は、標準フォーマットで、
.Li 0101010101010101
として与えられます。
.It N
.Ar key
は、NTP 標準で定められたフォーマットの 64-ビットの 16進数です。
これは、各オクテットを 1 ビット右 rotate して、パリティビットが
オクテットの上位ビットになったことを除いては、DES フォーマット
と同じです。先頭の 0 は省略できず、奇数パリティが保たれねばなりません。
0 鍵は、 NTP フォーマットで、
.Ar 8080808080808080
のように指定されます。
.It A
.Ar key
は 1 から 8 文字の ASCII 文字列です。鍵は、文字列中の各文字の
ASCII の下位 7 ビットを使用して構成されます。56-ビット幅の
鍵を作るために、 Unix パスワードから暗号化鍵を作るのと
同じ方法で、必要なら 0 が右端に付加されます。
.It M
.Ar key
は 1 から 8 文字の ASCII 文字列で、MD5 の認証方式を
使用しています。鍵と認証方式 (DES または MD5) の両方が、同じ鍵
番号を共有する一組の通信相手の間で一意である必要があることに
注意してください。
.El
.Pp
.Xr ntpq 8
と
.Xr ntpdc 8
プログラムで使用される鍵は、
プログラムによって要求されるパスワードに対してチェックされ、
また手動で入力されるため、ASCII 形式でこれらの鍵を指定することは
通常は適切です。
.Sh 関連ファイル
.Bl -tag -width /etc/ntp.drift -compact
.It Pa /etc/ntp.keys
デフォルトの設定ファイル名
.El
.Sh 関連項目
.Xr ntp.conf 5 ,
.Xr ntpd 8 ,
.Xr ntpdc 8 ,
.Xr ntpdate 8
.Sh 歴史
Delaware 大学の
.An David Mills
によって書かれました。
.Sh バグ
.Xr ntpd 8
はかなり大きくなってしまいました。巨大とは言いませんが、
ワークステーションで実行される高優先度のデーモンとして
望ましい大きさを超えてしまいました。
特に、高い階層 (stratum) のワークステーションよりは、
高負荷のプライマリサーバにあわせて、
かさばる凝った特徴の多くが設計されているからです。