[要約] RFC 2243は、OTP（One-Time Password）の拡張応答に関する仕様を定めたものであり、OTP認証プロトコルの機能を拡張するためのガイドラインを提供しています。このRFCの目的は、OTP認証のセキュリティと信頼性を向上させるために、拡張応答の仕組みを提供することです。
Network Working Group C. Metz
Request for Comments: 2243 The Inner Net
Category: Standards Track November 1997
OTP Extended Responses
OTP拡張応答
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
Abstract
概要
This document provides a specification for a type of response to an OTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented.
このドキュメントは、OTP [RFC 1938]チャレンジへの応答のタイプの仕様を提供します。これは、応答のエンコーディングを明示的に示します。この新しいタイプの応答を使用した2つの必須OTPデータ形式のコーディングを示します。
This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase.
このドキュメントでは、OTPジェネレーターがサーバーにシーケンスの再初期化とシークレットパスフレーズなどのパラメーターの変更を要求できるようにする応答の仕様も提供します。
This document specifies the data formats and software behaviors needed to use OTP extended responses. The data formats are described three ways: using an ad-hoc UNIX manual page style syntax, using augmented BNF described in sections two and three of RFC 822, and by examples. Should there be any conflict between these descriptions, the augmented BNF takes precedence. The software behaviors are described in words, and specific behavior compliance requirements are itemized using the requirements terminology (specifically, the words MUST, SHOULD, and MAY) defined in RFC 2119.
このドキュメントでは、OTP拡張応答を使用するために必要なデータ形式とソフトウェアの動作について説明します。データ形式は3つの方法で説明されています。アドホックUNIXマニュアルページスタイルの構文を使用するか、RFC 822のセクション2と3、および例で説明されている拡張BNFを使用します。これらの説明の間に矛盾がある場合は、拡張されたBNFが優先されます。ソフトウェアの動作は単語で記述され、特定の動作コンプライアンス要件は、RFC 2119で定義されている要件の用語（具体的には、MUST、SHOULD、およびMAY）を使用して項目化されています。
This document builds on the protocol and terminology specified in RFC 1938 and assumes that you have already read this document and understand its contents.
このドキュメントは、RFC 1938で指定されたプロトコルと用語に基づいており、このドキュメントを既に読んで内容を理解していることを前提としています。
An extended challenge is a single line of printable text terminated by either a new line sequence appropriate for the context of its use (e.g., ASCII CR followed by ASCII LF) or a whitespace character. It contains a standard OTP challenge, a whitespace character, and a list that generators use to determine which extended responses are supported by a server.
拡張チャレンジは、その使用状況に適した新しい行シーケンス（ASCII CRの後にASCII LFが続くなど）または空白文字で終了する印刷可能なテキストの1行です。これには、標準のOTPチャレンジ、空白文字、およびサーバーがサポートする拡張応答を決定するためにジェネレーターが使用するリストが含まれています。
An extended response is a single line of printable text terminated by a new line sequence appropriate for the context of its use. It contains two or more tokens that are separated with a single colon (':') character. The first token contains a type specifier that indicates the format of the rest of the response. The tokens that follow are argument data for the OTP extended response. At least one token of data MUST be present.
拡張応答は、その使用状況に適した新しい行シーケンスで終了する印刷可能なテキストの1行です。単一のコロン（ '：'）文字で区切られた2つ以上のトークンが含まれています。最初のトークンには、応答の残りの形式を示すタイプ指定子が含まれています。次のトークンは、OTP拡張応答の引数データです。少なくとも1つのデータトークンが存在する必要があります。
In UNIX manual page like syntax, the general form of an extended challenge could be described as:
構文のようなUNIXのマニュアルページでは、拡張チャレンジの一般的な形式は次のように記述できます。
<standard OTP challenge> ext[,<extension set id>[, ...]]
And the general form of an extended response could be described as:
また、拡張応答の一般的な形式は次のように説明できます。
<type-specifier>:<arg1>[:<arg2>[:...]]
In augmented BNF syntax, the syntax of the general form of an extended challenge and an extended response is:
拡張BNF構文では、拡張チャレンジと拡張応答の一般的な形式の構文は次のとおりです。
extended-challenge = otp-challenge 1*LWSP-char capability-list
(NL / *LWSP-char)
otp-challenge = <a standard OTP challenge>
capability-list = "ext" *("," extension-set-id)
extension-set-id = *<any CHAR except LWSP, CTLs, or ",">
extended-response = type 1*(":" argument) NL
type = token
argument = token
token = 1*<any CHAR except ":" and CTLs>
NL = <new line sequence appropriate for the context
in which OTP is being used>
An example of an extended challenge indicating support for OTP extended responses and for a mythical response set "foo" is:
OTP拡張応答と神秘的な応答セット「foo」のサポートを示す拡張チャレンジの例は次のとおりです。
otp-md5 123 mi1234 ext,foo
otp-md5 123 mi1234 ext、foo
An example of an extended response using a mythical type named "foo" is:
「foo」という名前の神話型を使用した拡張応答の例は次のとおりです。
foo:some data:some more data:12345
A server compliant with this specification:
この仕様に準拠したサーバー：
1. MUST be able to receive and parse the general form of an extended response 2. MUST be able to receive, parse, and correctly process all extended responses specified in this document 3. MUST process the type field in a case-insensitive manner 4. MUST reject any authentication attempt using an extended response if it does not support that type of response 5. SHOULD provide an appropriate indication to the generator if the response was rejected because of (4) 6. MUST limit the length of the input reasonably 7. MUST accept otherwise arbitrary amounts of whitespace wherever a response allows it 8. MUST be able to receive and correctly process standard OTP responses
1. 拡張応答の一般的な形式を受信および解析できる必要があります。2.このドキュメントで指定されているすべての拡張応答を受信、解析、および正しく処理できる必要があります。3.大文字と小文字を区別しない方法でtypeフィールドを処理する必要があります。そのタイプの応答をサポートしていない場合、拡張応答を使用した認証試行を拒否します。5。（4）のために応答が拒否された場合は、ジェネレータに適切な指示を提供する必要があります。6。入力の長さを合理的に制限する必要があります7。それ以外の場合は、応答が許可するところならどこでも任意の量の空白を受け入れる8.標準のOTP応答を受信して正しく処理できなければならない
A generator compliant with this specification:
この仕様に準拠したジェネレータ：
1. MUST be able to generate standard OTP responses 2. MUST use standard responses unless an extended challenge has been received for the particular server AND seed 3. MUST generate the type field in lower case 4. MUST NOT send a response type for which the server has not indicated support through an extended challenge
1. 標準のOTP応答を生成できる必要があります。2。特定のサーバーとシードの拡張チャレンジが受信されていない限り、標準の応答を使用する必要があります。3。小文字でタイプフィールドを生成する必要があります。4。サーバーの応答タイプを送信してはなりません。拡張チャレンジを通じてサポートを示していません
Extension set identifiers and extension type identifiers named with the prefix "x-" are reserved for private use among mutually consenting implementations. Implementations that do not recognise a particular "x-" extension MUST ignore that extension. This means that all "x-" extensions are likely to be non-interoperable with other extensions. Careful consideration should be given to the possibility of a server interacting with with a generator implementation which, although it recognizes a given "x-" extension, uses it for a different purpose. All of the remaining extension namespace is reserved to IANA, which will only officially assign the extension into this namespace after the IESG approves of such an assignment. During the lifetime of the OTP WG, it is recommended that the IESG consult with the OTP WG prior to approving such an assignment.
接頭辞「x-」で名前が付けられた拡張セット識別子と拡張タイプ識別子は、相互に同意する実装間での私的使用のために予約されています。特定の「x-」拡張を認識しない実装では、その拡張を無視する必要があります。これは、すべての「x-」拡張機能が他の拡張機能と相互運用できない可能性が高いことを意味します。サーバーがジェネレーター実装と相互作用する可能性については慎重に検討する必要があります。ジェネレーター実装は、特定の「x-」拡張を認識しますが、それを別の目的で使用します。残りのすべての拡張ネームスペースはIANAに予約されています。これは、IESGがそのような割り当てを承認した後にのみ、正式に拡張をこのネームスペースに割り当てます。 OTP WGの存続期間中、IESGはそのような割り当てを承認する前にOTP WGに相談することをお勧めします。
There exists a very rare case in which a standard OTP response could be a valid coding in both the hexadecimal and six-word formats. An example of this is the response "ABE ACE ADA ADD BAD A." The solution to this problem mandated by the OTP specification is that compliant servers MUST attempt to parse and verify a standard response in both hexadecimal and six-word formats and must consider the authentication successful if either succeeds.
標準のOTP応答が16進数形式と6語形式の両方で有効なコーディングになる非常にまれなケースがあります。この例は、「ABE ACE ADA ADD BAD A」という応答です。 OTP仕様で義務付けられているこの問題の解決策は、準拠サーバーが16進数と6ワードの両方の形式で標準応答を解析および検証する必要があり、どちらかが成功した場合に認証が成功したと見なす必要があることです。
This problem can be solved easily using extended responses. The "hex" response and the "word" response are two response types that encode an OTP in an extended response that explicitly describes the encoding. These responses start with a type label of "hex" for a hexadecimal OTP and "word" for a six-word coded OTP. These responses contain one argument field that contains a standard OTP response coded in the indicated format.
この問題は、拡張応答を使用して簡単に解決できます。 「hex」応答と「word」応答は、エンコードを明示的に記述する拡張応答でOTPをエンコードする2つの応答タイプです。これらの応答は、16進数のOTPの場合は「hex」、6ワードのコード化されたOTPの場合は「word」というタイプラベルで始まります。これらの応答には、指定された形式でコード化された標準OTP応答を含む1つの引数フィールドが含まれています。
In UNIX manual page like syntax, the format of these responses could be described as:
構文のようなUNIXのマニュアルページでは、これらの応答の形式は次のように記述できます。
hex:<hexadecimal number>
word:<six dictionary words>
In augmented BNF syntax and with the definitions already provided, the syntax of these responses is:
拡張BNF構文で、定義が既に提供されている場合、これらの応答の構文は次のとおりです。
hex-response = "hex:" hex-64bit NL
hex-64bit = 16(hex-char *LWSP-char)
hex-char = ("A" / "B" / "C" / "D" / "E" / "F" /
"a" / "b" / "c" / "d" / "e" / "f" /
"0" / "1" / "2" / "3" / "4" / "5" /
"6" / "7" / "8" / "9")
word-response = "word:" word-64bit NL
word-64bit = 6(otp-word 1*LWSP-char)
otp-word = <any valid word in the standard OTP coding
dictionary>
Examples of these responses are:
これらの応答の例は次のとおりです。
hex:8720 33d4 6202 9172 word:VAST SAUL TAKE SODA SUCH BOLT
hex：8720 33d4 6202 9172 word：VAST SAUL TAKE SODA SUCH BOLT
A server compliant with this specification:
この仕様に準拠したサーバー：
1. MUST process all arguments in a case-insensitive manner
1. 大文字と小文字を区別しない方法ですべての引数を処理する必要があります
A generator compliant with this specification:
この仕様に準拠したジェネレータ：
1. SHOULD generate otp-word tokens in upper case with single spaces separating them 2. SHOULD generate hexadecimal numbers using only lower case for letters
1. 大文字でotp-wordトークンを生成する必要があります（2つのスペースで区切ります）。2。文字には小文字のみを使用して16進数を生成する必要があります
The OTP specification requires that implementations provide a means for a client to re-initialize or change its OTP information with a server but does not require any specific protocol for doing it. Implementations that support the OTP extended responses described in this document MUST support the response with the "init-hex" and "init-word" type specifiers, which provide a standard way for a client to re-initialize its OTP information with a server. This response is intended to be used only by automated clients. Because of this, the recommended form of this response uses the hexadecimal encoding for binary data. It is possible for a user to type an "init-hex" or "init-word" response.
OTP仕様では、実装はクライアントがサーバーでOTP情報を再初期化または変更する手段を提供することを要求しますが、それを行うための特定のプロトコルを必要としません。このドキュメントで説明されているOTP拡張応答をサポートする実装は、クライアントがサーバーでOTP情報を再初期化するための標準的な方法を提供する「init-hex」および「init-word」タイプ指定子を使用して応答をサポートする必要があります。この応答は、自動クライアントのみが使用することを目的としています。このため、この応答の推奨形式では、バイナリデータに16進エンコーディングを使用します。ユーザーが「init-hex」または「init-word」応答を入力することは可能です。
In UNIX manual page like syntax, the format of these responses could be described as:
構文のようなUNIXのマニュアルページでは、これらの応答の形式は次のように記述できます。
init-hex:<current-OTP>:<new-params>:<new-OTP>
init-word:<current-OTP>:<new-params>:<new-OTP>
In augmented BNF syntax and with the definitions already provided, the syntax of the "init-hex" response is:
拡張BNF構文で、定義が既に提供されている場合、「init-hex」応答の構文は次のとおりです。
init-hex-response = "init-hex:" current-OTP ":" new-params ":"
new-OTP NL
current-OTP = hex-64bit
new-OTP = hex-64bit
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
In augmented BNF syntax and with the definitions already provided, the syntax of the "init-word" response is:
拡張BNF構文で、定義が既に提供されている場合、「init-word」応答の構文は次のとおりです。
init-word-response = "init-word:" current-OTP ":" new-params ":"
new-OTP NL
current-OTP = word-64bit new-OTP = word-64bit
current-OTP = word-64bit new-OTP = word-64bit
new-params = algorithm SPACE sequence-number SPACE seed
algorithm = "md4" / "md5" / "sha1"
sequence-number = 4*3DIGIT
seed = 16*1(ALPHA / DIGIT)
Note that all appropriate fields for the "init-hex" response MUST be hexadecimally coded and that all appropriate fields for the "init-word" response MUST be six-word coded.
「init-hex」応答のすべての適切なフィールドは16進数でコーディングする必要があり、「init-word」応答のすべての適切なフィールドは6ワードでコーディングする必要があることに注意してください。
Examples of these responses are:
これらの応答の例は次のとおりです。
init-hex:f6bd 6b33 89b8 7203:md5 499 ke6118:23d1 b253 5ae0 2b7e
init-hex:c9b2 12bb 6425 5a0f:md5 499 ke0986:fd17 cef1 b4df 093e
init-word:MOOD SOFT POP COMB BOLO LIFE:md5 499 ke1235:
ARTY WEAR TAD RUG HALO GIVE
init-word:END KERN BALM NICK EROS WAVY:md5 499 ke1235:
BABY FAIN OILY NIL TIDY DADE
(Note that all of these responses are one line. Due to their length, they had to be split into multiple lines in order to be included here. These responses MUST NOT span more than one line in actual use)
（これらの応答はすべて1行です。これらの長さのため、ここに含めるには複数行に分割する必要がありました。これらの応答は、実際の使用では複数行にまたがってはなりません）
The current-OTP field contains the (RFC 1938) response to the OTP challenge. The new-params field contains the parameters for the client's new requested challenge and the new-OTP field contains a response to that challenge. If the re-initialization is successful, a server MUST store the new OTP in its database as the last successful OTP received and the sequence number in the next challenge presented by the server MUST be one less than the sequence number specified in the new-params field.
現在のOTPフィールドには、OTPチャレンジに対する（RFC 1938）応答が含まれています。 new-paramsフィールドには、クライアントの新しく要求されたチャレンジのパラメーターが含まれ、new-OTPフィールドには、そのチャレンジへの応答が含まれます。再初期化が成功した場合、サーバーは最後に成功したOTPを受信したときにデータベースに新しいOTPを保存する必要があり、サーバーによって提示される次のチャレンジのシーケンス番号は、new-paramsで指定されたシーケンス番号より1つ小さい必要がありますフィールド。
The new-params field is hashed as a string the same way that a seed or secret pass phrase would be. All other field values are hashed in their uncoded binary forms, in network byte order and without any padding.
new-paramsフィールドは、シードまたはシークレットパスフレーズと同じ方法で文字列としてハッシュされます。他のすべてのフィールド値は、コード化されていないバイナリ形式で、ネットワークバイト順で、パディングなしでハッシュされます。
A server compliant with this specification:
この仕様に準拠したサーバー：
1. SHOULD NOT allow a user to use the same value for their seed and secret pass phrase. 2. MUST disable all OTP access to any principal whose sequence number would be less than one 3. MUST decrement the sequence number if a reinitialization response includes a valid current-OTP, but the server is unable to successfully process the new-params or new-OTP for any reason.
1. ユーザーがシードとシークレットパスフレーズに同じ値を使用することを許可しないでください。 2.シーケンス番号が1未満になるプリンシパルへのすべてのOTPアクセスを無効にする必要があります3.再初期化応答に有効な現在のOTPが含まれているが、サーバーがnew-paramsまたはnewを正常に処理できない場合は、シーケンス番号をデクリメントする必要があります。 -OTP何らかの理由。
A generator compliant with this specification:
この仕様に準拠したジェネレータ：
1. SHOULD NOT allow a user to use the same value for their seed and secret pass phrase 2. MUST take specific steps to prevent infinite loops of re-initialization attempts in case of failure 3. SHOULD provide the user with some indication that the re-initialization is taking place 4. SHOULD NOT do a re-initialization without the user's permission, either for that specific instance or as a configuration option 5. SHOULD NOT retry a failed re-initialization without a user's permission 6. SHOULD warn the user if the sequence number falls below ten 7. MUST refuse to generate OTPs with a sequence number below one
1. ユーザーがシードとシークレットパスフレーズに同じ値を使用することを許可しないでください。2。失敗した場合に再初期化の試行が無限ループになるのを防ぐために特定の手順を実行する必要があります。3。ユーザーに再初期化の指示を提供する必要があります（SHOULD）。その特定のインスタンスに対して、または構成オプションとして、ユーザーの許可なしに再初期化を行うべきではありません。5.ユーザーの許可なしに失敗した再初期化を再試行すべきではありません。6.シーケンスの場合、ユーザーに警告する必要があります（SHOULD NOT）。番号は10を下回る7.シーケンス番号が1未満のOTPの生成を拒否する必要がある
All of the security considerations for the OTP system also apply to the OTP system with extended responses.
OTPシステムのセキュリティに関する考慮事項はすべて、拡張応答を使用するOTPシステムにも適用されます。
These extended responses, like OTP itself, do not protect the user against active attacks. The IPsec Authentication Header (RFC-1826) (or another technique with at least as much strength as IPsec AH) SHOULD be used to protect against such attacks.
OTP自体のようなこれらの拡張応答は、アクティブな攻撃からユーザーを保護しません。 IPsec認証ヘッダー（RFC-1826）（または、少なくともIPsec AHと同等の強度を持つ別の手法）を使用して、このような攻撃から保護する必要があります。
The consequences of a successful active attack on the re-initialization response may be more severe than simply hijacking a single session. An attacker could substitute his own response for that of a legitimate user. The attacker may then be able to use the OTP system to authenticate himself as the user at will (at least until detected).
再初期化応答に対するアクティブな攻撃が成功した場合の結果は、単に単一のセッションを乗っ取るよりも深刻な場合があります。攻撃者は、正当なユーザーの応答を自分の応答に置き換える可能性があります。攻撃者は、OTPシステムを使用して、ユーザーが自由に（少なくとも検出されるまで）自分自身を認証できる可能性があります。
Failure to implement server requirement 3 in section 4.3 opens an implementation to an attack based on replay of the current-OTP part of the response.
セクション4.3のサーバー要件3の実装に失敗すると、応答の現在のOTP部分の再生に基づく攻撃の実装が開かれます。
Like RFC 1938, the protocol described in this document was created by contributors in the IETF OTP working group. Specific contributions were made by Neil Haller, who provided input on the overall design requirements of a re-initialization protocol, Denis Pinkas, who suggested several modifications to the originally proposed re-initialization protocol, and Phil Servita, who opened the debate with the first real protocol proposal and provided lots of specific input on the design of this and earlier protocols. The extensions to the OTP challenge were suggested by Chris Newman and John Valdes.
RFC 1938と同様に、このドキュメントで説明されているプロトコルは、IETF OTPワーキンググループの寄稿者によって作成されました。具体的な貢献は、再初期化プロトコルの全体的な設計要件に関する情報を提供したニールハラー、最初に提案された再初期化プロトコルへのいくつかの変更を提案したデニスピンカス、および最初の議論を開始したフィルサービタによって行われました。実際のプロトコルの提案と、このプロトコルと以前のプロトコルの設計に関する多くの特定の入力を提供しました。 OTPチャレンジの拡張は、Chris NewmanとJohn Valdesによって提案されました。
Randall Atkinson and Ted T'so also contributed their views to discussions about details of the protocol extensions in this document.
Randall AtkinsonとTed T'soも、このドキュメントのプロトコル拡張の詳細についての議論に彼らの見解を提供しました。
References
参考文献
[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages," RFC 822, August 1982.
[RFC 822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、RFC 822、1982年8月。
[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol," RFC 1825, August 1995.
[RFC 1825] Atkinson、R。、「Security Protocol for the Internet Protocol」、RFC 1825、1995年8月。
[RFC 1938] Haller, N. and C. Metz, "A One-Time Password System," RFC 1938, May 1996.
[RFC 1938] Haller、N。およびC. Metz、「A One-Time Password System」、RFC 1938、1996年5月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level," RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
Author's Address
著者のアドレス
Craig Metz The Inner Net Box 10314-1936 Blacksburg, VA 24062-0314 (DSN) 354-8590 cmetz@inner.net
Craig Metz The Inner Net Box 10314-1936 Blacksburg、VA 24062-0314（DSN）354-8590 cmetz@inner.net
Appendix: Reference Responses
付録：参照応答
The following responses were generated by a development version of the One-Time Passwords in Everything (OPIE) implementation of this specification.
次の応答は、この仕様のワンタイムパスワード（OPIE）実装の開発バージョンによって生成されました。
All of these are responses to the challenge:
これらはすべて、課題への対応です。
otp-md5 499 ke1234 ext
otp-md5 499 ke1234 ext
Note that the re-initialization responses use the same secret pass phrase for new and current and a new seed of "ke1235". Also, these responses have been split for formatting purposes into multiple lines; they MUST NOT be multiple lines in actual use.
再初期化応答は、「ke1235」の新しいシードと現在のシード、および新しいシードに同じ秘密のパスフレーズを使用することに注意してください。また、これらの応答は、フォーマットのために複数行に分割されています。実際の使用では、それらは複数行であってはなりません。
The secret pass phrase for these responses is:
これらの応答の秘密のパスフレーズは次のとおりです。
This is a test.
これはテストです。
The OTP standard hexadecimal response is:
OTP標準16進数応答は次のとおりです。
5bf0 75d9 959d 036f
5bf0 75d9 959d 036f
The OTP standard six-word response is:
OTP標準の6ワード応答は次のとおりです。
BOND FOGY DRAB NE RISE MART
BOND FOGY DRAB NE RISE MART
The OTP extended "hex" response is:
OTP拡張「hex」応答は次のとおりです。
hex:5Bf0 75d9 959d 036f
hex：5Bf0 75d9 959d 036f
The OTP extended "word" response is:
OTP拡張「ワード」応答は次のとおりです。
word:BOND FOGY DRAB NE RISE MART
ワード：BOND FOGY DRAB NE RISE MART
The OTP extended "init-hex" response is:
OTP拡張「init-hex」応答は次のとおりです。
init-hex:5bf0 75d9 959d 036f:md5 499 ke1235:3712 dcb4 aa53 16c1
The OTP extended "init-word" response is:
OTP拡張「init-word」応答は次のとおりです。
init-word:BOND FOGY DRAB NE RISE MART:md5 499 ke1235: RED HERD NOW BEAN PA BURG
init-word：BOND FOGY DRAB NE RISE MART：md5 499 ke1235：RED HERD NOW BEAN PA BURG
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。