[要約] RFC 2433は、Microsoft PPP CHAP拡張機能に関する仕様であり、PPP接続における認証プロトコルの拡張を提供します。目的は、より強力な認証機能を提供し、セキュリティを向上させることです。
Network Working Group G. Zorn
Request for Comments: 2433 S. Cobb
Category: Informational Microsoft Corporation
October 1998
Microsoft PPP CHAP Extensions
Microsoft PPP CHAP拡張
Status of this 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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG Note
IESG Note
The protocol described here has significant vulnerabilities. People planning on implementing or using this protocol should read section 12, "Security Considerations".
ここで説明するプロトコルには重大な脆弱性があります。このプロトコルの実装または使用を計画している人は、セクション12「セキュリティに関する考慮事項」を読む必要があります。
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
ポイントツーポイントプロトコル（PPP）[1]は、ポイントツーポイントリンクを介してマルチプロトコルデータグラムを転送する標準的な方法を提供します。 PPPは、さまざまなネットワーク層プロトコルを確立および構成するための拡張可能なリンク制御プロトコルとネットワーク制御プロトコル（NCP）のファミリを定義します。
This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which extends the user authentication functionality provided on Windows networks to remote workstations. MS-CHAP is closely derived from the PPP Challenge Handshake Authentication Protocol described in RFC 1994 [2], which the reader should have at hand.
このドキュメントでは、MicrosoftのPPP CHAPダイアレクト（MS-CHAP）について説明します。これは、Windowsネットワークで提供されるユーザー認証機能をリモートワークステーションに拡張します。 MS-CHAPは、RFC 1994 [2]で説明されているPPPチャレンジハンドシェイク認証プロトコルから密接に派生しています。
The algorithms used in the generation of various MS-CHAP protocol fields are described in an appendix.
さまざまなMS-CHAPプロトコルフィールドの生成に使用されるアルゴリズムについては、付録で説明します。
Microsoft created MS-CHAP to authenticate remote Windows workstations, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks.
マイクロソフトは、リモートWindowsワークステーションを認証するためにMS-CHAPを作成し、Windowsネットワークで使用される暗号化およびハッシュアルゴリズムを統合しながら、LANベースのユーザーが慣れている機能を提供しました。
Where possible, MS-CHAP is consistent with standard CHAP. Briefly, the differences between MS-CHAP and standard CHAP are:
可能な場合、MS-CHAPは標準のCHAPと一致しています。簡単に言うと、MS-CHAPと標準CHAPの違いは次のとおりです。
* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP option 3, Authentication Protocol.
* MS-CHAPは、LCPオプション3、認証プロトコルでCHAPアルゴリズム0x80をネゴシエートすることで有効になります。
* The MS-CHAP Response packet is in a format designed for compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and Windows95 networking products. The MS-CHAP format does not require the authenticator to store a clear-text or reversibly encrypted password.
* MS-CHAP応答パケットは、MicrosoftのWindows NT 3.5、3.51および4.0、およびWindows95ネットワーク製品との互換性のために設計された形式です。 MS-CHAP形式では、オーセンティケータがクリアテキストまたは可逆的に暗号化されたパスワードを保存する必要はありません。
* MS-CHAP provides authenticator-controlled authentication retry and password changing mechanisms.
* MS-CHAPは、オーセンティケーター制御の認証再試行およびパスワード変更メカニズムを提供します。
* MS-CHAP defines a set of reason-for-failure codes returned in the Failure packet Message field.
* MS-CHAPは、Failure packet Messageフィールドで返される一連の理由コードを定義します。
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
このドキュメントでは、キーワード「MAY」、「MUST、「MUST NOT」、「optional」、「recommended」、「SHOULD」、および「SHOULD NOT」は、[2]で説明されているように解釈されます。
The LCP configuration for MS-CHAP is identical to that for standard CHAP, except that the Algorithm field has value 0x80, rather than the MD5 value 0x05. PPP implementations which do not support MS-CHAP, but correctly implement LCP Config-Rej, should have no problem dealing with this non-standard option.
MS-CHAPのLCP構成は、アルゴリズムフィールドの値がMD5値0x05ではなく0x80であることを除いて、標準CHAPの構成と同じです。 MS-CHAPをサポートしないが、LCP Config-Rejを正しく実装するPPP実装は、この非標準オプションの処理に問題がないはずです。
The MS-CHAP Challenge packet is identical in format to the standard CHAP Challenge packet.
MS-CHAPチャレンジパケットの形式は、標準のCHAPチャレンジパケットと同じです。
MS-CHAP authenticators send an 8-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 8-octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
MS-CHAP認証システムは、8オクテットのチャレンジ値フィールドを送信します。ピアは、8オクテット値を選択するためにMicrosoftのアルゴリズムを複製する必要はありませんが、ランダム性に関する標準ガイドライン[1,2,7]を遵守する必要があります。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
Microsoftオーセンティケーターは現在、「名前」フィールドに情報を提供していません。これは将来変更される可能性があります。
The MS-CHAP Response packet is identical in format to the standard CHAP Response packet. However, the Value field is sub-formatted differently as follows:
MS-CHAP応答パケットの形式は、標準のCHAP応答パケットと同じです。ただし、[値]フィールドは、次のようにサブフォーマットが異なります。
24 octets: LAN Manager compatible challenge response 24 octets: Windows NT compatible challenge response 1 octet : "Use Windows NT compatible challenge response" flag
24オクテット：LAN Manager互換チャレンジレスポンス24オクテット：Windows NT互換チャレンジレスポンス1オクテット：「Windows NT互換チャレンジレスポンスを使用する」フラグ
The LAN Manager compatible challenge response is an encoded function of the password and the received challenge as output by the routine LmChallengeResponse() (see section A.1, below). LAN Manager passwords are limited to 14 case-insensitive OEM characters. Note that use of the LAN Manager compatible challenge response has been deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be zero-filled. The algorithm used in the generation of the LAN Manager compatible challenge response is described here for informational purposes only.
LAN Manager互換のチャレンジ応答は、パスワードのエンコードされた関数であり、ルーチンLmChallengeResponse()からの出力として受信したチャレンジです（以下のセクションA.1を参照）。 LAN Managerパスワードは、大文字と小文字を区別しない14文字のOEM文字に制限されています。 LAN Manager互換のチャレンジ応答の使用は推奨されていないことに注意してください。ピアはそれを生成してはならず（SHOULD NOT）、サブフィールドはゼロで埋める必要があります（SHOULD）。 LAN Manager互換のチャレンジ応答の生成に使用されるアルゴリズムは、情報提供のみを目的としてここで説明されています。
The Windows NT compatible challenge response is an encoded function of the password and the received challenge as output by the routine NTChallengeResponse() (see section A.5, below). The Windows NT password is a string of 0 to (theoretically) 256 case-sensitive Unicode [8] characters. Current versions of Windows NT limit passwords to 14 characters, mainly for compatibility reasons; this may change in the future.
Windows NT互換のチャレンジ応答は、パスワードのエンコードされた関数であり、ルーチンNTChallengeResponse()からの出力として受信したチャレンジです（以下のセクションA.5を参照）。 Windows NTのパスワードは、0〜（理論的には）256文字の大文字と小文字が区別されるUnicode [8]文字の文字列です。現在のバージョンのWindows NTは、主に互換性の理由から、パスワードを14文字に制限しています。これは将来変更される可能性があります。
The "use Windows NT compatible challenge response" flag, if 1, indicates that the Windows NT response is provided and should be used in preference to the LAN Manager response. The LAN Manager response will still be used if the account does not have a Windows NT password hash, e.g. if the password has not been changed since the account was uploaded from a LAN Manager 2.x account database. If the flag is 0, the Windows NT response is ignored and the LAN Manager response is used. Since the use of LAN Manager authentication has been deprecated, this flag SHOULD always be set (1) and the LAN Manager compatible challenge response field SHOULD be zero-filled.
「Windows NT互換チャレンジ応答を使用する」フラグが1の場合、Windows NT応答が提供されており、LAN Manager応答よりも優先して使用する必要があることを示します。アカウントにWindows NTパスワードハッシュがない場合、LAN Managerの応答は引き続き使用されます。アカウントがLAN Manager 2.xアカウントデータベースからアップロードされてからパスワードが変更されていない場合。フラグが0の場合、Windows NT応答は無視され、LAN Manager応答が使用されます。 LAN Manager認証の使用は推奨されていないため、このフラグは常に設定（SHOULD）する必要があり（1）、LAN Manager互換のチャレンジ応答フィールドはゼロで埋める必要があります（SHOULD）。
The Name field identifies the peer's user account name. The Windows NT domain name may prefix the user's account name (e.g. "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the user account "john-doe"). If a domain is not provided, the backslash should also be omitted, (e.g. "johndoe").
Nameフィールドは、ピアのユーザーアカウント名を識別します。 Windows NTドメイン名は、ユーザーのアカウント名の前に付けることができます（例：「BIGCO \ johndoe」。「BIGCO」は、ユーザーアカウント「john-doe」を含むWindows NTドメインです）。ドメインが提供されていない場合は、円記号も省略する必要があります（「johndoe」など）。
The Success packet is identical in format to the standard CHAP Success packet.
Successパケットは、標準のCHAP Successパケットと形式が同じです。
The Failure packet is identical in format to the standard CHAP Failure packet. There is, however, formatted text stored in the Message field which, contrary to the standard CHAP rules, affects the protocol. The Message field format is:
障害パケットの形式は、標準のCHAP障害パケットと同じです。ただし、標準のCHAPルールとは異なり、プロトコルに影響を与えるフォーマットされたテキストがメッセージフィールドに格納されます。メッセージフィールドの形式は次のとおりです。
"E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
where
ただし
The "eeeeeeeeee" is the decimal error code (need not be 10 digits) corresponding to one of those listed below, though implementations should deal with codes not on this list gracefully.
「eeeeeeeeee」は、以下にリストされているものの1つに対応する10進数のエラーコード（10桁である必要はありません）ですが、実装はこのリストにないコードを適切に処理する必要があります。
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
646 ERROR_RESTRICTED_LOGON_HOURS 647 ERROR_ACCT_DISABLED 648 ERROR_PASSWD_EXPIRED 649 ERROR_NO_DIALIN_PERMISSION 691 ERROR_AUTHENTICATION_FAILURE 709 ERROR_CHANGING_PASSWORD
The "r" is a flag set to "1" if a retry is allowed, and "0" if not. When the authenticator sets this flag to "1" it disables short timeouts, expecting the peer to prompt the user for new credentials and resubmit the response.
「r」は、再試行が許可される場合は「1」に設定され、許可されない場合は「0」に設定されるフラグです。オーセンティケーターがこのフラグを「1」に設定すると、短いタイムアウトが無効になり、ピアがユーザーに新しい資格情報を要求して応答を再送信することが期待されます。
The "cccccccccccccccc" is 16 hexadecimal digits representing an ASCII representation of a new challenge value. This field is optional. If it is not sent, the authenticator expects the resubmitted response to be calculated based on the previous challenge value plus decimal 23 in the first octet, i.e. the one immediately following the Value Size field. Windows 95 authenticators may send this field. Windows NT authenticators do not, but may in the future. Both systems implement peer support of this field.
「cccccccccccccccc」は、新しいチャレンジ値のASCII表現を表す16桁の16進数です。このフィールドはオプションです。送信されない場合、オーセンティケータは、再送信された応答が、前のチャレンジ値に最初のオクテットの10進数23を加えたものに基づいて計算されることを期待します。 Windows 95オーセンティケーターがこのフィールドを送信する場合があります。 Windows NTオーセンティケーターはサポートしていませんが、将来的にはサポートする予定です。どちらのシステムも、このフィールドのピアサポートを実装しています。
The "vvvvvvvvvv" is the decimal version code (need not be 10 digits) indicating the MS-CHAP protocol version supported on the server. Currently, this is interesting only in selecting a Change Password packet type. If the field is not present the version should be assumed to be 1; since use of the version 1 Change Password packet has been deprecated, this field SHOULD always contain a value greater than or equal to 2.
「vvvvvvvvvv」は、サーバーでサポートされているMS-CHAPプロトコルのバージョンを示す10進数のバージョンコード（10桁である必要はありません）です。現在、これは、パスワードの変更パケットタイプを選択する場合にのみ重要です。フィールドが存在しない場合、バージョンは1と見なされます。バージョン1のパスワード変更パケットの使用は推奨されていないため、このフィールドには常に2以上の値を含める必要があります（SHOULD）。
Implementations should accept but ignore additional text they do not recognize.
実装は、認識しない追加のテキストを受け入れますが無視します。
The version 1 Change Password packet does not appear in standard CHAP. It allows the peer to change the password on the account specified in the previous Response packet. The version 1 Change Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one in the Message field of the Failure packet.
バージョン1のパスワード変更パケットは、標準のCHAPでは表示されません。これにより、ピアは前の応答パケットで指定されたアカウントのパスワードを変更できます。バージョン1のパスワード変更パケットは、オーセンティケータがERROR_PASSWD_EXPIRED（E = 648）を報告し、Vが見つからないか、失敗パケットのメッセージフィールドに1と等しい場合にのみ送信する必要があります。
The use of the Change Password Packet (version 1) has been deprecated; the format of the packet is described here for informational purposes, but peers SHOULD NOT transmit it.
パスワード変更パケット（バージョン1）の使用は廃止されました。パケットのフォーマットは情報提供の目的でここで説明されていますが、ピアはそれを送信してはいけません。
The format of this packet is as follows:
このパケットの形式は次のとおりです。
1 octet : Code (=5)
1 octet : Identifier
2 octets: Length (=72)
16 octets: Encrypted LAN Manager Old password Hash
16 octets: Encrypted LAN Manager New Password Hash
16 octets: Encrypted Windows NT Old Password Hash
16 octets: Encrypted Windows NT New Password Hash
2 octets: Password Length
2 octets: Flags
Code 5
コード5
Identifier The Identifier field is one octet and aids in matching requests and replies. The value is the Identifier of the received Failure packet to which this packet responds plus 1.
Identifier Identifierフィールドは1オクテットで、要求と応答の照合に役立ちます。値は、このパケットが応答する受信障害パケットのID + 1です。
Length 72
長さ72
Encrypted LAN Manager New Password Hash Encrypted LAN Manager Old Password Hash These fields contain the LAN Manager password hash of the new and old passwords encrypted with the last received challenge value, as output by the routine LmEncryptedPasswordHash() (see section A.8, below).
暗号化されたLANマネージャーの新しいパスワードハッシュ暗号化されたLANマネージャーの古いパスワードハッシュこれらのフィールドには、ルーチンLmEncryptedPasswordHash()による出力として、最後に受信したチャレンジ値で暗号化された新しいパスワードと古いパスワードのLANマネージャーパスワードハッシュが含まれます（以下のセクションA.8を参照）。 ）。
Encrypted Windows NT New Password Hash Encrypted Windows NT Old Password Hash These fields contain the Windows NT password hash of the new and old passwords encrypted with the last received challenge value, as output by the pseudo-code routine NtEncryptedPasswordHash() (see section A.10, below).
暗号化されたWindows NTの新しいパスワードハッシュ暗号化されたWindows NTの古いパスワードハッシュこれらのフィールドには、擬似コードルーチンNtEncryptedPasswordHash()による出力として、最後に受信したチャレンジ値で暗号化された新しいパスワードと古いパスワードのWindows NTパスワードハッシュが含まれます（セクションAを参照）。 10、以下）。
Password Length The length in octets of the LAN Manager compatible form of the new password. If this value is greater than or equal to zero and less than or equal to 14 it is assumed that the encrypted LAN Manager password hash fields are valid. Otherwise, it is assumed these fields are not valid, in which case the Windows NT compatible passwords MUST be provided.
パスワードの長さ新しいパスワードのLAN Manager互換形式のオクテット単位の長さ。この値がゼロ以上14以下の場合、暗号化されたLAN Managerパスワードハッシュフィールドは有効であると見なされます。それ以外の場合、これらのフィールドは無効であると見なされます。その場合、Windows NT互換のパスワードを指定する必要があります。
Flags This field is two octets in length. It is a bit field of option flags where 0 is the least significant bit of the 16-bit quantity:
フラグこのフィールドの長さは2オクテットです。これはオプションフラグのビットフィールドであり、0は16ビット量の最下位ビットです。
Bit 0 If this bit is set (1), it indicates that the encrypted Windows NT hashed passwords are valid and should be used. If this bit is cleared (0), the Windows NT fields are not used and the LAN Manager fields must be provided.
ビット0このビットが設定されている場合（1）、暗号化されたWindows NTハッシュパスワードが有効であり、使用する必要があることを示します。このビットがクリアされている場合（0）、Windows NTフィールドは使用されず、LAN Managerフィールドを提供する必要があります。
Bits 1-15 Reserved, always clear (0).
ビット1〜15予約済み、常にクリア（0）。
The version 2 Change Password packet does not appear in standard CHAP. It allows the peer to change the password on the account specified in the preceding Response packet. The version 2 Change Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the Message field of the Failure packet.
バージョン2のパスワード変更パケットは、標準のCHAPでは表示されません。これにより、ピアは前の応答パケットで指定されたアカウントのパスワードを変更できます。バージョン2のパスワード変更パケットは、オーセンティケータがERROR_PASSWD_EXPIRED（E = 648）を報告し、失敗パケットのメッセージフィールドに2以上のバージョンを報告する場合にのみ送信する必要があります。
This packet type is supported by Windows NT 3.51, 4.0 and recent versions of Windows 95. It is not supported by Windows NT 3.5 or early versions of Windows 95.
このパケットタイプは、Windows NT 3.51、4.0、およびWindows 95の最新バージョンでサポートされています。WindowsNT 3.5またはそれ以前のバージョンのWindows 95ではサポートされていません。
The format of this packet is as follows:
このパケットの形式は次のとおりです。
1 octet : Code 1 octet : Identifier 2 octets : Length 516 octets : Password Encrypted with Old NT Hash
1オクテット：コード1オクテット：識別子2オクテット：長さ516オクテット：古いNTハッシュで暗号化されたパスワード
16 octets : Old NT Hash Encrypted with New NT Hash 516 octets : Password Encrypted with Old LM Hash 16 octets : Old LM Hash Encrypted With New NT Hash 24 octets : LAN Manager compatible challenge response 24 octets : Windows NT compatible challenge response 2-octet : Flags
16オクテット：新しいNTハッシュで暗号化された古いNTハッシュ516オクテット：古いLMハッシュで暗号化されたパスワード16オクテット：新しいNTハッシュで暗号化された古いLMハッシュ24オクテット：LAN Manager互換チャレンジレスポンス24オクテット：Windows NT互換チャレンジレスポンス2オクテット：フラグ
Code 6
コード6
Identifier The Identifier field is one octet and aids in matching requests and replies. The value is the Identifier of the received Failure packet to which this packet responds plus 1.
Identifier Identifierフィールドは1オクテットで、要求と応答の照合に役立ちます。値は、このパケットが応答する受信障害パケットのID + 1です。
Length 1118
長さ1118
Password Encrypted with Old NT Hash This field contains the PWBLOCK form of the new Windows NT password encrypted with the old Windows NT password hash, as output by the NewPasswordEncryptedWithOldNtPasswordHash() routine (see section A.11, below).
古いNTハッシュで暗号化されたパスワードこのフィールドには、NewPasswordEncryptedWithOldNtPasswordHash()ルーチンによる出力として、古いWindows NTパスワードハッシュで暗号化された新しいWindows NTパスワードのPWBLOCKフォームが含まれます（以下のセクションA.11を参照）。
Old NT Hash Encrypted with New NT Hash This field contains the old Windows NT password hash encrypted with the new Windows NT password hash, as output by the OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see section A.14, below).
新しいNTハッシュで暗号化された古いNTハッシュこのフィールドには、OldNtPasswordHashEncryptedWithNewNtPasswordHash()ルーチンによる出力として、新しいWindows NTパスワードハッシュで暗号化された古いWindows NTパスワードハッシュが含まれます（以下のセクションA.14を参照）。
Password Encrypted with Old LM Hash This field contains the PWBLOCK form of the new Windows NT password encrypted with the old LAN Manager password hash, as output by the NewPasswordEncryptedWithOldLmPasswordHash() routine described in section A.15, below. Note, however, that the use of this field has been deprecated: peers SHOULD NOT generate it, and this field SHOULD be zero-filled.
古いLMハッシュで暗号化されたパスワードこのフィールドには、以下のセクションA.15で説明するNewPasswordEncryptedWithOldLmPasswordHash()ルーチンによる出力として、古いLAN Managerパスワードハッシュで暗号化された新しいWindows NTパスワードのPWBLOCKフォームが含まれます。ただし、このフィールドの使用は推奨されていないことに注意してください。ピアはフィールドを生成してはならず（SHOULD NOT）、このフィールドはゼロで埋める必要があります（SHOULD）。
Old LM Hash Encrypted With New NT Hash This field contains the old LAN Manager password hash encrypted with the new Windows NT password hash, as output by the OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see section A.16, below). Note, however, that the use of this field has been deprecated: peers SHOULD NOT generate it, and this field SHOULD be zero-filled.
新しいNTハッシュで暗号化された古いLMハッシュこのフィールドには、OldLmPasswordHashEncryptedWithNewNtPasswordHash()ルーチンによる出力として、新しいWindows NTパスワードハッシュで暗号化された古いLAN Managerパスワードハッシュが含まれます（以下のセクションA.16を参照）。ただし、このフィールドの使用は推奨されていないことに注意してください。ピアはフィールドを生成してはならず（SHOULD NOT）、このフィールドはゼロで埋める必要があります（SHOULD）。
LAN Manager compatible challenge response Windows NT compatible challenge response The challenge response field (as described in the Response packet description), but calculated on the new password and the same challenge used in the last response. Note that use of the LAN Manager compatible challenge response has been deprecated; peers SHOULD NOT generate it, and the field SHOULD be zero-filled.
LAN Manager互換チャレンジレスポンスWindows NT互換チャレンジレスポンスチャレンジレスポンスフィールド（レスポンスパケットの説明で説明）ですが、新しいパスワードと、最後のレスポンスで使用されたのと同じチャレンジで計算されます。 LAN Manager互換のチャレンジ応答の使用は推奨されていないことに注意してください。ピアはそれを生成すべきではなく（SHOULD NOT）、フィールドはゼロで埋めるべきです（SHOULD）。
Flags This field is two octets in length. It is a bit field of option flags where 0 is the least significant bit of the 16-bit quantity. The format of this field is illustrated in the following diagram:
フラグこのフィールドの長さは2オクテットです。これはオプションフラグのビットフィールドであり、0は16ビット量の最下位ビットです。このフィールドの形式を次の図に示します。
1
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 0 The "use Windows NT compatible challenge response" flag as described in the Response packet.
ビット0応答パケットで説明されている「Windows NT互換チャレンジ応答を使用する」フラグ。
Bit 1 Set (1) indicates that the "Password Encrypted with Old LM Hash" and "Old LM Hash Encrypted With New NT Hash" fields are valid and should be used. Clear (0) indicates these fields are not valid. This bit SHOULD always be clear (0).
ビット1セット（1）は、「古いLMハッシュで暗号化されたパスワード」および「新しいNTハッシュで暗号化された古いLMハッシュ」フィールドが有効であり、使用する必要があることを示します。クリア（0）は、これらのフィールドが無効であることを示します。このビットは常にクリア（0）である必要があります。
Bits 2-15 Reserved, always clear (0).
ビット2〜15予約済み、常にクリア（0）。
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
実装の詳細として、オーセンティケータは、ブルートフォースパスワード推測攻撃をより困難にするために許可されるパスワード再試行の数を制限する必要があります（SHOULD）。
Because the challenge value is encrypted using the password hash to form the response and the challenge is transmitted in clear-text form, both passive known-plaintext and active chosen-plaintext attacks against the password hash are possible. Suitable precautions (i.e., frequent password changes) SHOULD be taken in environments where eavesdropping is likely.
チャレンジ値はパスワードハッシュを使用して暗号化されて応答を形成し、チャレンジはクリアテキスト形式で送信されるため、パスワードハッシュに対するパッシブな既知プレーンテキスト攻撃とアクティブな選択プレーンテキスト攻撃の両方が可能です。盗聴される可能性のある環境では、適切な予防策（パスワードの頻繁な変更など）を行う必要があります。
The Change Password (version 1) packet is vulnerable to a passive eavesdropping attack which can easily reveal the new password hash. For this reason, it MUST NOT be sent if eavesdropping is possible.
パスワード変更（バージョン1）パケットは、パッシブ盗聴攻撃に対して脆弱であり、新しいパスワードハッシュを簡単に明らかにする可能性があります。このため、盗聴が可能な場合は送信しないでください。
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[2] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[2] シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] "Data Encryption Standard (DES)", Federal Information Processing Standard Publication 46-2, National Institute of Standards and Technology, December 1993.
[4] 「データ暗号化標準（DES）」、連邦情報処理標準出版物46-2、国立標準技術研究所、1993年12月。
[5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992.
[5] Rivest、R。、「MD4 Message Digest Algorithm」、RFC 1320、1992年4月。
[6] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact: RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
[6] RC4は、RSA Data Security Inc.からのライセンスに基づいて利用できる独自の暗号化アルゴリズムです。ライセンス情報については、RSA Data Security、Inc.までお問い合わせください。100Marine Parkway Redwood City、CA 94065-1031
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recomnendations for Security", RFC 1750, December 1994.
[7] Eastlake、D.、Crocker、S。、およびJ. Schiller、「Randomness Recomnendations for Security」、RFC 1750、1994年12月。
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9.
[8] 「The Unicode Standard、Version 2.0」、The Unicode Consortium、Addison-Wesley、1996。ISBN0-201-48345-9。
[9] "DES Modes of Operation", Federal Information Processing Standards Publication 81, National Institute of Standards and Technology, December 1980
[9] 「DES Modes of Operation」、Federal Information Processing Standards Publication 81、National Institute of Standards and Technology、1980年12月
Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), Bill Palter (palter@network-alchemy.com), Bruce Johnson (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) for useful suggestions and feedback.
Jeff Haag（Jeff_Haag@3com.com）、Bill Palter（palter@network-alchemy.com）、Bruce Johnson（bjohnson@microsoft.com）、Tony Bell（tonybe@microsoft.com）に（順不同で）感謝します。 Benoit Martin（ehlija@vircom.com）、およびJoe Davies（josephd@microsoft.com）は、有用な提案とフィードバックを提供しています。
The PPP Extensions Working Group can be contacted via the current chair:
PPP Extensionsワーキンググループは、現在の議長を通じて連絡を取ることができます。
Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, OH 43221
Karl Fox Ascend Communications 3518 Riverside Drive Suite 101コロンバス、オハイオ州43221
Phone: +1 614 326 6841
EMail: karl@ascend.com
Questions about this memo can also be directed to:
このメモに関する質問は、次の宛先にも送信できます。
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052
グレンゾーンマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン98052
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: glennz@microsoft.com
Steve Cobb Microsoft Corporation One Microsoft Way Redmond, Washington 98052
Steve Cobb Microsoft Corporation One Microsoft Wayワシントン州レドモンド98052
EMail: stevec@microsoft.com
Appendix A - Pseudocode
付録A-疑似コード
The routines mentioned in the text are described in pseudocode below.
本文で言及されているルーチンは、以下の疑似コードで説明されています。
LmChallengeResponse(
IN 8-octet Challenge,
IN 0-to-14-oem-char Password,
OUT 24-octet Response )
{
LmPasswordHash( Password, giving PasswordHash )
ChallengeResponse( Challenge, PasswordHash, giving Response )
}
LmPasswordHash( IN 0-to-14-oem-char Password, OUT 16-octet PasswordHash ) { Set UcasePassword to the uppercased Password Zero pad UcasePassword to 14 characters
LmPasswordHash（IN 0-to-14-oem-char Password、OUT 16-octet PasswordHash）{UcasePasswordを大文字のパスワードゼロパッドに設定UcasePasswordを14文字
DesHash( 1st 7-octets of UcasePassword, giving 1st 8-octets of PasswordHash )
DesHash（UcasePasswordの最初の7オクテット、PasswordHashの最初の8オクテットを与える）
DesHash( 2nd 7-octets of UcasePassword, giving 2nd 8-octets of PasswordHash ) }
DesHash（UcasePasswordの2番目の7オクテット、PasswordHashの2番目の8オクテット）}
DesHash(
IN 7-octet Clear,
OUT 8-octet Cypher )
{
/*
* Make Cypher an irreversibly encrypted form of Clear by
* encrypting known text using Clear as the secret key.
* The known text consists of the string
*
* KGS!@#$%
*/
Set StdText to "KGS!@#$%" DesEncrypt( StdText, Clear, giving Cypher ) }
StdTextを "KGS！@＃$％"に設定しますDesEncrypt（StdText、Clear、give Cypher）}
DesEncrypt(
IN 8-octet Clear,
IN 7-octet Key,
OUT 8-octet Cypher )
{
/*
* Use the DES encryption algorithm [4] in ECB mode [9]
* to encrypt Clear into Cypher such that Cypher can
* only be decrypted back to Clear by providing Key.
* Note that the DES algorithm takes as input a 64-bit
* stream where the 8th, 16th, 24th, etc. bits are
* parity bits ignored by the encrypting algorithm.
* Unless you write your own DES to accept 56-bit input
* without parity, you will need to insert the parity bits
* yourself.
*/
}
NtChallengeResponse(
IN 8-octet Challenge,
IN 0-to-256-unicode-char Password,
OUT 24-octet Response )
{
NtPasswordHash( Password, giving PasswordHash )
ChallengeResponse( Challenge, PasswordHash, giving Response )
}
NtPasswordHash(
IN 0-to-256-unicode-char Password,
OUT 16-octet PasswordHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash Password
* into PasswordHash. Only the password is hashed without
* including any terminating 0.
*/
}
｝
ChallengeResponse( IN 8-octet Challenge, IN 16-octet PasswordHash, OUT 24-octet Response ) { Set ZPasswordHash to PasswordHash zero-padded to 21 octets
ChallengeResponse（IN 8オクテットチャレンジ、IN 16オクテットPasswordHash、OUT 24オクテット応答）{ZPasswordHashをPasswordHashに設定し、ゼロパディングして21オクテットにする
DesEncrypt( Challenge, 1st 7-octets of ZPasswordHash, giving 1st 8-octets of Response )
DesEncrypt（チャレンジ、ZPasswordHashの最初の7オクテット、最初の8オクテットの応答）
DesEncrypt( Challenge, 2nd 7-octets of ZPasswordHash, giving 2nd 8-octets of Response )
DesEncrypt（チャレンジ、ZPasswordHashの2番目の7オクテット、2番目の8オクテットの応答）
DesEncrypt( Challenge, 3rd 7-octets of ZPasswordHash, giving 3rd 8-octets of Response ) }
DesEncrypt（チャレンジ、ZPasswordHashの3番目の7オクテット、3番目の8オクテットの応答）}
LmEncryptedPasswordHash( IN 0-to-14-oem-char Password, IN 8-octet KeyValue, OUT 16-octet Cypher ) { LmPasswordHash( Password, giving PasswordHash )
LmEncryptedPasswordHash（IN 0-to-14-oem-char Password、IN 8-octet KeyValue、OUT 16-octet Cypher）{LmPasswordHash（Password、given PasswordHash）
PasswordHashEncryptedWithBlock( PasswordHash, KeyValue, giving Cypher ) }
PasswordHashEncryptedWithBlock（PasswordHash、KeyValue、Give Cypher）}
PasswordHashEncryptedWithBlock( IN 16-octet PasswordHash, IN 8-octet Block, OUT 16-octet Cypher ) {
PasswordHashEncryptedWithBlock（IN 16-octet PasswordHash、IN 8-octet Block、OUT 16-octet Cypher）{
DesEncrypt( 1st 8-octets PasswordHash, 1st 7-octets Block, giving 1st 8-octets Cypher )
DesEncrypt（最初の8オクテットPasswordHash、1番目の7オクテットブロック、最初の8オクテットの暗号を与える）
DesEncrypt( 2nd 8-octets PasswordHash, 1st 7-octets Block, giving 2nd 8-octets Cypher ) }
DesEncrypt（2番目の8オクテットPasswordHash、1番目の7オクテットブロック、2番目の8オクテットの暗号を与える）}
NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet Challenge OUT 16-octet Cypher ) { NtPasswordHash( Password, giving PasswordHash )
NtEncryptedPasswordHash（IN 0-to-14-oem-char Password IN 8-octet Challenge OUT 16-octet Cypher）{NtPasswordHash（Password、given PasswordHash）
PasswordHashEncryptedWithBlock( PasswordHash, Challenge, giving Cypher ) }
PasswordHashEncryptedWithBlock（PasswordHash、Challenge、Giveing Cypher）}
datatype-PWBLOCK
{
256-unicode-char Password
4-octets PasswordLength
}
NewPasswordEncryptedWithOldNtPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT datatype-PWBLOCK EncryptedPwBlock ) { NtPasswordHash( OldPassword, giving PasswordHash )
NewPasswordEncryptedWithOldNtPasswordHash（IN 0-to-256-unicode-char NewPassword、IN 0-to-256-unicode-char OldPassword、OUT datatype-PWBLOCK EncryptedPwBlock）{NtPasswordHash（OldPassword、PasswordHashを与える）
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, giving EncryptedPwBlock ) }
EncryptPwBlockWithPasswordHash（NewPassword、PasswordHash、EncryptedPwBlockを与える）}
EncryptPwBlockWithPasswordHash( IN 0-to-256-unicode-char Password, IN 16-octet PasswordHash, OUT datatype-PWBLOCK PwBlock ) {
EncryptPwBlockWithPasswordHash（IN 0-to-256-unicode-char Password、IN 16-octet PasswordHash、OUT datatype-PWBLOCK PwBlock）{
Fill ClearPwBlock with random octet values
PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
ClearPwBlock.PasswordLength = PwSize
Rc4Encrypt( ClearPwBlock,
sizeof( ClearPwBlock ),
PasswordHash,
sizeof( PasswordHash ),
giving PwBlock )
}
Rc4Encrypt(
IN x-octet Clear,
IN integer ClearLength,
IN y-octet Key,
IN integer KeyLength,
OUT x-octet Cypher )
{
/*
* Use the RC4 encryption algorithm [6] to encrypt Clear of
* length ClearLength octets into a Cypher of the same length
* such that the Cypher can only be decrypted back to Clear
* by providing a Key of length KeyLength octets.
*/
}
OldNtPasswordHashEncryptedWithNewNtPasswordHash(
IN 0-to-256-unicode-char NewPassword,
IN 0-to-256-unicode-char OldPassword,
OUT 16-octet EncryptedPasswordHash )
{
NtPasswordHash( OldPassword, giving OldPasswordHash )
NtPasswordHash( NewPassword, giving NewPasswordHash )
NtPasswordHashEncryptedWithBlock( OldPasswordHash,
NewPasswordHash,
giving EncryptedPasswordHash )
}
NewPasswordEncryptedWithOldLmPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT datatype-PWBLOCK EncryptedPwBlock ) { LmPasswordHash( OldPassword, giving PasswordHash )
NewPasswordEncryptedWithOldLmPasswordHash（IN 0-to-256-unicode-char NewPassword、IN 0-to-256-unicode-char OldPassword、OUT datatype-PWBLOCK EncryptedPwBlock）{LmPasswordHash（OldPassword、given PasswordHash）
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, giving EncryptedPwBlock ) }
EncryptPwBlockWithPasswordHash（NewPassword、PasswordHash、EncryptedPwBlockを与える）}
OldLmPasswordHashEncryptedWithNewNtPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT 16-octet EncryptedPasswordHash ) { LmPasswordHash( OldPassword, giving OldPasswordHash )
OldLmPasswordHashEncryptedWithNewNtPasswordHash（IN 0-to-256-unicode-char NewPassword、IN 0-to-256-unicode-char OldPassword、OUT 16-octet EncryptedPasswordHash）{LmPasswordHash（OldPassword、OldPasswordHashを与える）
NtPasswordHash( NewPassword, giving NewPasswordHash )
NtPasswordHash（NewPassword、NewPasswordHashを与える）
NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash, giving EncrytptedPasswordHash ) }
NtPasswordHashEncryptedWithBlock（OldPasswordHash、NewPasswordHash、EncrytptedPasswordHashを与える）}
NtPasswordHashEncryptedWithBlock( IN 16-octet PasswordHash, IN 16-octet Block, OUT 16-octet Cypher ) { DesEncrypt( 1st 8-octets PasswordHash, 1st 7-octets Block, giving 1st 8-octets Cypher )
NtPasswordHashEncryptedWithBlock（IN 16-octet PasswordHash、IN 16-octet Block、OUT 16-octet Cypher）{DesEncrypt（1st 8-octets PasswordHash、1st 7-octets Block、given 1st 8-octets Cypher）
DesEncrypt( 2nd 8-octets PasswordHash, 2nd 7-octets Block, giving 2nd 8-octets Cypher ) }
DesEncrypt（2番目の8オクテットPasswordHash、2番目の7オクテットブロック、2番目の8オクテットの暗号を与える）}
Appendix B - Examples
付録B-例
Here are some examples of typical negotiations. The peer is on the left and the authenticator is on the right.
以下は、典型的な交渉の例です。ピアは左側にあり、オーセンティケータは右側にあります。
The packet sequence ID is incremented on each authentication retry Response and on the change password response. All cases where the packet sequence ID is updated are noted below.
パケットシーケンスIDは、各認証再試行応答およびパスワード変更応答で増分されます。パケットシーケンスIDが更新されるすべてのケースを以下に示します。
Response retry is never allowed after Change Password. Change Password may occur after Response retry. The implied challenge form is shown in the examples, though all cases of "first challenge+23" should be replaced by the "C=cccccccccccccccc" challenge if authenticator supplies it in the Failure packet.
パスワード変更後の応答の再試行は決して許可されません。応答の再試行後にパスワードの変更が発生する場合があります。暗黙のチャレンジフォームが例に示されていますが、「最初のチャレンジ+ 23」のすべてのケースは、オーセンティケータが失敗パケットで提供した場合、「C = cccccccccccccccc」チャレンジに置き換える必要があります。
<- Challenge Response -> <- Success
<-チャレンジレスポンス-> <-成功
<- Challenge
Response ->
<- Failure (E=691 R=0)
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Success
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23+23 ->
<- Failure (E=691 R=0)
<- Challenge
Response ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge ->
<- Success
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge+23 ->
<- Success
Intermediate values for password "MyPw".
パスワード「MyPw」の中間値。
8-octet Challenge: 10 2D B5 DF 08 5D 30 41
8オクテットチャレンジ：10 2D B5 DF 08 5D 30 41
0-to-256-unicode-char NtPassword: 4D 00 79 00 50 00 77 00
0-to-256-unicode-char NtPassword：4D 00 79 00 50 00 77 00
16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16オクテットNtPasswordHash：FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
24-octet NtChallengeResponse: 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C A4 C3 51 AB 40 9A 3D 61
24オクテットNtChallengeResponse：4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C A4 C3 51 AB 40 9A 3D 61
DES uses 56-bit keys, expanded to 64 bits by the insertion of parity bits. After the parity of the key has been fixed, every eighth bit is a parity bit and the number of bits that are set (1) in each octet is odd; i.e., odd parity. Note that many DES engines do not check parity, however, simply stripping the parity bits. The following example illustrates the values resulting from the use of the 16-octet NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
DESは、パリティビットの挿入により64ビットに拡張された56ビットキーを使用します。キーのパリティが修正された後、8ビットごとがパリティビットになり、各オクテットに設定されるビット数（1）は奇数になります。つまり、奇数パリティです。多くのDESエンジンはパリティをチェックしないことに注意してください。ただし、パリティビットを削除するだけです。次の例は、付録B.2に示す16オクテットのNTPasswordHashを使用して、DES鍵のペアを生成した結果の値を示しています。
(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in Appendix A.17).
（たとえば、付録A.17で説明されているNtPasswordHashEncryptedWithBlock()で使用するため）。
16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16オクテットNtPasswordHash：FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
First "raw" DES key (initial 7 octets of password hash): FC 15 6A F7 ED CD 6C
最初の「生の」DESキー（パスワードハッシュの最初の7オクテット）：FC 15 6A F7 ED CD 6C
First parity-corrected DES key (eight octets): FD 0B 5B 5E 7F 6E 34 D9
最初のパリティ訂正済みDES鍵（8オクテット）：FD 0B 5B 5E 7F 6E 34 D9
Second "raw" DES key (second 7 octets of password hash) 0E DD E3 33 7D 42 7F
2番目の「生の」DESキー（パスワードハッシュの2番目の7オクテット）0E DD E3 33 7D 42 7F
Second parity-corrected DES key (eight octets): 0E 6E 79 67 37 EA 08 FE
2番目のパリティ訂正済みDES鍵（8オクテット）：0E 6E 79 67 37 EA 08 FE
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。