Network Working Group G. Zorn
Request for Comments: 2759 Microsoft Corporation
Category: Informational January 2000
Microsoft PPP CHAP Extensions, Version 2
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 (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
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 version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication.
このドキュメントは、MicrosoftのPPP CHAP方言（MS-CHAP-V2）のバージョン2を説明します。 MS-CHAP-V2は次のように、しかしと互換性のない、MS-CHAPバージョン1（〔9〕に記載のMS-CHAP-V1）です。具体的には、特定のプロトコルフィールドはなく、異なる意味を持つ削除または再利用されています。加えて、MS-CHAP-V2は、相互認証を特徴とします。
The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9.
部9に設けられている種々のMS-CHAP-V2プロトコルフィールドの生成に使用されるアルゴリズムは、セクション8ネゴシエーションおよびハッシュ生成実施例に記載されています。
Specification of Requirements
要件の仕様
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [3].
この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" [3]で説明されるように解釈されるべきではありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3
3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3
4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6
8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7
8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8
8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9
8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9
8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9
8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10
8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10
8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12
8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12
8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13
8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14
8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15
9.1.2. Authenticator authentication failure . . . . . . . . . . . 15
9.1.3. Failed authentication with no retry allowed . . . . . . . . 15
9.1.4. Successful authentication after retry . . . . . . . . . . . 15
9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15
9.1.6. Successful authentication with password change . . . . . . 16
9.1.7. Successful authentication with retry and password change. . 16
9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20
Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS-CHAP-V1 are:
可能な場合、MS-CHAP-V2は、MS-CHAP-V1および標準CHAPの両方と一致しています。簡潔には、MS-CHAP-V2およびMS-CHAP-V1の違いは次のとおりです。
* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP option 3, Authentication Protocol.
* MS-CHAP-V2は、LCPオプション3、認証プロトコルでCHAPアルゴリズム0x81との交渉で有効になっています。
* MS-CHAP-V2 provides mutual authentication between peers by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet.
* MS-CHAP-V2は、応答パケットにピアチャレンジ、成功パケットにオーセンティケータ応答をピギーバックすることによって、ピア間の相互認証を提供します。
* The calculation of the "Windows NT compatible challenge response" sub-field in the Response packet has been changed to include the peer challenge and the user name.
*応答パケットの「Windows NT互換性のあるチャレンジレスポンス」サブフィールドの計算は、ピアチャレンジとユーザー名を含むように変更されました。
* In MS-CHAP-V1, the "LAN Manager compatible challenge response" sub-field was always sent in the Response packet. This field has been replaced in MS-CHAP-V2 by the Peer-Challenge field.
* MS-CHAP-V1では、「LAN Managerの互換性のあるチャレンジレスポンス」サブフィールドは常に応答パケットに送信されました。このフィールドは、ピアチャレンジフィールドでMS-CHAP-V2に置き換えられました。
* The format of the Message field in the Failure packet has been changed.
*失敗パケット内のメッセージフィールドのフォーマットが変更されました。
* The Change Password (version 1) and Change Password (version 2) packets are no longer supported. They have been replaced with a single Change-Password packet.
*パスワードの変更（バージョン1）およびパスワードの変更（バージョン2）パケットはサポートされなくなりました。彼らは、単一の変更、パスワードのパケットに置き換えられました。
The LCP configuration for MS-CHAP-V2 is identical to that for standard CHAP, except that the Algorithm field has value 0x81, rather than the MD5 value 0x05. PPP implementations which do not support MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no problem dealing with this non-standard option.
MS-CHAP-V2用のLCP構成は、アルゴリズムフィールドではなくMD5値0x05のより、値0x81とを有することを除いて、標準のCHAPの場合と同じです。 MS-CHAP-V2をサポートしていますが、正しくLCPコンフィグ-レジを実装していないPPP実装は、この非標準オプションを扱う問題はないはずです。
The MS-CHAP-V2 Challenge packet is identical in format to the standard CHAP Challenge packet.
MS-CHAP-V2チャレンジパケットは、標準的なCHAPチャレンジパケットのフォーマットと同一です。
MS-CHAP-V2 authenticators send an 16-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 16- octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
MS-CHAP-V2オーセンティケータは、16オクテットチャレンジ値フィールドを送信します。ピアは16オクテット値を選択するためのMicrosoftのアルゴリズムを複製する必要はないが、ランダム[1,2,7]上の標準的なガイドラインが観察されなければなりません。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
マイクロソフトオーセンティケータは、現在、[名前]フィールドに情報を提供していません。これは、将来的に変更されることがあります。
The MS-CHAP-V2 Response packet is identical in format to the standard CHAP Response packet. However, the Value field is sub-formatted differently as follows:
MS-CHAP-V2応答パケットは、標準のCHAP応答パケットのフォーマットと同一です。ただし、値フィールドは、以下の異なったように、サブフォーマットされます。
16 octets: Peer-Challenge 8 octets: Reserved, must be zero 24 octets: NT-Response 1 octet : Flags
16オクテット：ピア・チャレンジ8つのオクテット：予約、ゼロ24オクテットでなければなりません：NT-レスポンス1つのオクテット：フラグ
The Peer-Challenge field is a 16-octet random number. As the name implies, it is generated by the peer and is used in the calculation of the NT-Response field, below. Peers need not duplicate Microsoft's algorithm for selecting the 16-octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
ピアチャレンジフィールドは16オクテット乱数です。名前が示すように、ピアによって生成され、以下、NT-応答フィールドの計算に使用されます。ピアは16オクテットの値を選択するためのMicrosoftのアルゴリズムを複製する必要はないが、ランダム[1,2,7]上の標準的なガイドラインが観察されなければなりません。
The NT-Response field is an encoded function of the password, the user name, the contents of the Peer-Challenge field and the received challenge as output by the routine GenerateNTResponse() (see section 8.1, 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. When computing the NT-Response field contents, only the user name is used, without any associated Windows NT domain name. This is true regardless of whether a Windows NT domain name is present in the Name field (see below).
NT-応答フィールドは、パスワードの符号化機能、ユーザ名、ピアチャレンジフィールドの内容及びルーチンGenerateNTResponse（により出力として受信したチャレンジ）（以下、セクション8.1を参照）です。 Windows NTのパスワードは（理論的に）256大文字と小文字を区別ユニコード[8]文字0の文字列です。主に互換性の理由のために、14文字までのWindows NT制限のパスワードの現在のバージョン、。これは将来的に変更されることがあります。 NT-レスポンスフィールドの内容を計算する場合、ユーザー名のみが関連するすべてのWindows NTドメイン名を指定せずに、使用されています。これは、（下記参照）にかかわらず、Windows NTドメイン名が名前フィールドに存在するかどうかの事実です。
The Flag field is reserved for future use and MUST be zero.
フラグフィールドは、将来の使用のために予約されており、ゼロでなければなりません。
The Name field is a string of 0 to (theoretically) 256 case-sensitive ASCII characters which 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 "johndoe"). If a domain is not provided, the backslash should also be omitted, (e.g. "johndoe").
[名前]フィールドには、ピアのユーザーアカウント名を特定する（理論上）256大文字と小文字を区別ASCII文字に0の文字列です。 Windows NTドメイン名は、ユーザーのアカウント名（「BIGCOは、」ユーザーアカウント「JOHNDOE」を含むWindows NTドメインである、例えば「BIGCO \ JOHNDOEを」）の接頭辞があります。ドメインが提供されていない場合、バックスラッシュは、（例えば、「JOHNDOE」）、省略すべきです。
The Success packet is identical in format to the standard CHAP Success packet. However, the Message field contains a 42-octet authenticator response string and a printable message. The format of the message field is illustrated below.
Successパケットは、標準のCHAP成功パケットにフォーマットと同一です。ただし、メッセージフィールドは42オクテットオーセンティケータの応答文字列と印刷可能なメッセージが含まれています。メッセージ・フィールドのフォーマットを以下に示します。
"S=<auth_string> M=<message>"
"S = <auth_string> M = <メッセージ>"
The <auth_string> quantity is a 20 octet number encoded in ASCII as 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST be uppercase. This number is derived from the challenge from the Challenge packet, the Peer-Challenge and NT-Response fields from the Response packet, and the peer password as output by the routine GenerateAuthenticatorResponse() (see section 8.7, below). The authenticating peer MUST verify the authenticator response when a Success packet is received. The method for verifying the authenticator is described in section 8.8, below. If the authenticator response is either missing or incorrect, the peer MUST end the session.
<auth_string>量は40桁の16進数として、ASCIIで符号化された20オクテットの数です。 16進数字-Fは、（存在する場合）は大文字でなければなりません。この数は、（）（以下、8.7節を参照してください）チャレンジパケット、ピア・チャレンジとレスポンスパケットからNT-レスポンスフィールド、およびルーチンGenerateAuthenticatorResponseによって出力としてピア・パスワードからチャレンジから導出されます。 Successパケットを受信したときに認証するピアは、認証応答を確かめなければなりません。オーセンティケータを検証するための方法は、以下のセクション8.8に記載されています。オーセンティケータ応答が欠けているか間違っていた場合、ピアは、セッションを終了する必要があります。
The <message> quantity is human-readable text in the appropriate charset and language [12].
<メッセージ>量は、適切な文字セットと言語[12]における人間可読テキストです。
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, does affect the operation of the protocol. The Message field format is:
失敗パケットは、標準のCHAP失敗パケットのフォーマットと同一です。 、プロトコルの動作に影響を与えない、標準のCHAPのルールに反して、メッセージフィールドに格納されている、しかし、フォーマットされたテキストがあります。メッセージフィールドの形式は次のとおりです。
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv M=<msg>"
"E = eeeeeeeeee R = R C = cccccccccccccccccccccccccccccccc V = vvvvvvvvvv M = <MSG>"
where
どこ
The "eeeeeeeeee" is the ASCII representation of a 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進数のエラーコードのASCII表現です。
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 an ASCII 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」でない場合に設定ASCIIフラグです。オーセンティケータが「1」にこのフラグを設定すると、それは新しい資格情報をユーザーに要求し、応答を再送信するためにピアを期待して、短いタイムアウトを無効にします。
The "cccccccccccccccccccccccccccccccc" is the ASCII representation of a hexadecimal challenge value. This field MUST be exactly 32 octets long and MUST be present.
「ccccccccccccccccccccccccccccccccは」進挑戦値のASCII表現です。このフィールドは、正確に32オクテット長さでなければならないと存在しなければなりません。
The "vvvvvvvvvv" is the ASCII representation of a decimal version code (need not be 10 digits) indicating the password changing protocol version supported on the server. For MS-CHAP-V2, this value SHOULD always be 3.
「vvvvvvvvvv」は、小数点バージョンのコードのASCII表現であるサーバ上に支持されたパスワード変更プロトコルのバージョンを示す（10桁である必要はありません）。 MS-CHAP-V2の場合、この値は常に3であるべきです。
<msg> is human-readable text in the appropriate charset and language [12].
<MSG>適切な文字セットと言語[12]における人間可読テキストです。
The Change-Password packet does not appear in either standard CHAP or MS-CHAP-V1. It allows the peer to change the password on the account specified in the preceding Response packet. The Change-Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure packet.
パスワード変更パケットは、標準のCHAPまたはMS-CHAP-V1のいずれかに表示されません。これは、ピアが、先行する応答パケットに指定されたアカウントのパスワードを変更することができます。パスワード変更パケットは、認証が失敗パケットのメッセージ欄にERROR_PASSWD_EXPIRED（E = 648）を報告した場合にのみ送信する必要があります。
This packet type is supported by recent versions of Windows NT 4.0, Windows 95 and Windows 98. It is not supported by Windows NT 3.5, Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and Windows 98.
このパケットタイプは、これがWindows NT 3.5、Windows NTの3.51、またはWindows NT 4.0の初期のバージョン、Windows 95およびWindows 98でサポートされていないWindows NT 4.0、Windows 95およびWindows 98の最近のバージョンでサポートされています。
The format of this packet is as follows:
次のようにこのパケットのフォーマットは次のとおりです。
1 octet : Code 1 octet : Identifier 2 octets : Length 516 octets : Encrypted-Password 16 octets : Encrypted-Hash 16 octets : Peer-Challenge 8 octets : Reserved 24 octets : NT-Response 2-octet : Flags
1オクテット：コード1つのオクテット：識別子2つのオクテット：長さ516オクテット：暗号化、パスワード16オクテット：暗号化、ハッシュ16オクテット：ピアチャレンジ8つのオクテット：予約24オクテット：NT-応答2オクテット：フラグ
Code 7
コード7
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.
識別子ザ識別子フィールドは、要求と応答のマッチングに1オクテットおよびAIDSです。値は、このパケットが応答プラス1の受信失敗パケットの識別子です。
Length 586
長さ586
Encrypted-Password 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 8.9, below).
暗号化・パスワードこのフィールドは、（以下のセクション8.9を参照してください）NewPasswordEncryptedWithOldNtPasswordHash（）ルーチンによって出力として、古いのWindows NTパスワードハッシュで暗号化された新しいWindows NTパスワードのPWBLOCKフォームが含まれています。
Encrypted-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 8.12, below).
暗号化 - ハッシュこのフィールドはOldNtPasswordHashEncryptedWithNewNtPasswordHash（）ルーチンによって出力として（以下、セクション8.12を参照）、新しいWindows NTパスワードハッシュで暗号化された古いWindows NTのパスワードのハッシュが含まれています。
Peer-Challenge A 16-octet random quantity, as described in the Response packet description.
応答パケットの説明に記載されているように、16オクテットのランダム量をピアチャレンジ。
Reserved 8 octets, must be zero.
予約済み8つのオクテットは、ゼロでなければなりません。
NT-Response The NT-Response field (as described in the Response packet description), but calculated on the new password and the challenge received in the Failure packet.
NT-レスポンスザ・NT-レスポンスフィールド（Responseパケットの説明で説明したように）が、新しいパスワードと失敗パケットで受信したチャレンジに基づいて計算。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 0-15 Reserved, always clear (0).
ビット0-15予約済み、常にクリア（0）。
The routines mentioned in the text above are described in pseudocode in the following sections.
上記本文中に記載のルーチンは、次のセクションで擬似コードで記述されています。
GenerateNTResponse( IN 16-octet AuthenticatorChallenge, IN 16-octet PeerChallenge,
GenerateNTResponse（16オクテットのAuthenticatorChallenge、16オクテットのPeerChallenge、
IN 0-to-256-char UserName,
0から256のcharユーザー名では、
IN 0-to-256-unicode-char Password, OUT 24-octet Response ) { 8-octet Challenge 16-octet PasswordHash
）0から256ユニコード文字パスワードIN、OUT 24オクテット応答{8オクテットチャレンジ16オクテットPasswordHash
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge)
ChallengeHash（PeerChallenge、AuthenticatorChallenge、ユーザー名、与えチャレンジ）
NtPasswordHash( Password, giving PasswordHash ) ChallengeResponse( Challenge, PasswordHash, giving Response ) }
チャレンジ - レスポンス（応答を与えるチャレンジ、PasswordHash）}（PasswordHashを与えるパスワード）NtPasswordHash
ChallengeHash( IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, OUT 8-octet Challenge {
ChallengeHash（16オクテットPeerChallenge IN、16オクテットAuthenticatorChallenge IN、0から256文字のユーザー名IN、OUT 8オクテットチャレンジ{
/*
* SHAInit(), SHAUpdate() and SHAFinal() functions are an
* implementation of Secure Hash Algorithm (SHA-1) [11]. These are
* available in public domain or can be licensed from
* RSA Data Security, Inc.
*/
SHAInit(Context) SHAUpdate(Context, PeerChallenge, 16) SHAUpdate(Context, AuthenticatorChallenge, 16)
SHAInit（コンテキスト）SHAUpdate（コンテキスト、PeerChallenge、16）SHAUpdate（コンテキスト、AuthenticatorChallenge、16）
/*
* Only the user name (as presented by the peer and
* excluding any prepended domain name)
* is used as input to SHAUpdate().
*/
SHAUpdate(Context, UserName, strlen(Username)) SHAFinal(Context, Digest) memcpy(Challenge, Digest, 8) }
SHAUpdate（コンテキスト、ユーザ名、strlenを（ユーザ名））SHAFinal（コンテキスト、ダイジェスト）のmemcpy（チャレンジ、ダイジェスト、8）}
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.
*/
}
HashNtPasswordHash(
IN 16-octet PasswordHash,
OUT 16-octet PasswordHashHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash
* PasswordHash into PasswordHashHash.
*/
}
ChallengeResponse( IN 8-octet Challenge, IN 16-octet PasswordHash, OUT 24-octet Response ) { Set ZPasswordHash to PasswordHash zero-padded to 21 octets
チャレンジ - レスポンス（8オクテットチャレンジIN、16オクテットPasswordHash IN、OUT 24オクテット応答）{セットZPasswordHash 21オクテットまでゼロパディングをPasswordHashします
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（応答の第2の8オクテットを与えるZPasswordHashのチャレンジ、第2 7オクテット）
DesEncrypt( Challenge, 3rd 7-octets of ZPasswordHash, giving 3rd 8-octets of Response ) }
DESENCRYPT（チャレンジ、応答の第3の8オクテットを与えるZPasswordHashの3 7オクテット）}
DesEncrypt(
IN 8-octet Clear,
IN 7-octet Key,
OUT 8-octet Cypher )
{
/*
* Use the DES encryption algorithm [4] in ECB mode [10]
* 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.
*/
}
GenerateAuthenticatorResponse( IN 0-to-256-unicode-char Password, IN 24-octet NT-Response, IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, OUT 42-octet AuthenticatorResponse ) { 16-octet PasswordHash 16-octet PasswordHashHash 8-octet Challenge
GenerateAuthenticatorResponse（0・ツー・256・ユニコード・文字のパスワードでは、24オクテットNT-応じて、16オクテットのPeerChallenge、AuthenticatorChallenge 16オクテットでは、0から256文字のUserName IN、OUT 42オクテットAuthenticatorResponse） {16オクテットPasswordHash 16オクテットPasswordHashHash 8オクテットチャレンジ
/*
* "Magic" constants used in response generation
*/
Magic1[39] = {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74};
Magic1 [39] = {0x4D、の0x61、0x67、0x69の、は0x63、0x20に、0x73、0x65、0x72、0x76、0x65、0x72、0x20に、0x74、0x6F、0x20に、は0x63、0x6C、0x69の、0x65、0x6E、0x74、 0x20、0x73、0x69の、0x67、0x6E、0x69の、0x6E、0x67、0x20に、は0x63、0x6F、0x6E、0x73、0x74、の0x61、0x6E、0x74}。
Magic2[41] = {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 0x6E};
Magic2 [41] = {0x50を、の0x61、0x64、0x20に、0x74、0x6F、0x20に、0x6D、の0x61、0x6B、0x65、0x20に、0x69の、0x74、0x20に、0x64、0x6F、0x20に、0x6D、0x6F、0x72、0x65、 0x20、0x74、0x68、の0x61、0x6E、0x20に、0x6F、0x6E、0x65、0x20に、0x69の、0x74、0x65、0x72、の0x61、0x74、0x69の、0x6F、0x6E}。
/*
* Hash the password with MD4
*/
NtPasswordHash( Password, giving PasswordHash )
NtPasswordHash（パスワード、PasswordHashを与えます）
/*
* Now hash the hash
*/
HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
HashNtPasswordHash（PasswordHash、与えPasswordHashHash）
SHAInit(Context) SHAUpdate(Context, PasswordHashHash, 16) SHAUpdate(Context, NTResponse, 24) SHAUpdate(Context, Magic1, 39) SHAFinal(Context, Digest)
SHAInit（コンテキスト）SHAUpdate（コンテキスト、PasswordHashHash、16）SHAUpdate（コンテキスト、NTResponse、24）SHAUpdate（コンテキスト、Magic1、39）SHAFinal（コンテキスト、ダイジェスト）
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge)
ChallengeHash（PeerChallenge、AuthenticatorChallenge、ユーザー名、与えチャレンジ）
SHAInit(Context) SHAUpdate(Context, Digest, 20) SHAUpdate(Context, Challenge, 8) SHAUpdate(Context, Magic2, 41) SHAFinal(Context, Digest)
SHAInit（コンテキスト）SHAUpdate（コンテキスト、ダイジェスト、20）SHAUpdate（コンテキスト、チャレンジ、8）SHAUpdate（コンテキスト、Magic2、41）SHAFinal（コンテキスト、ダイジェスト）
/*
* Encode the value of 'Digest' as "S=" followed by
* 40 ASCII hexadecimal digits and return it in
* AuthenticatorResponse.
* For example,
* "S=0123456789ABCDEF0123456789ABCDEF01234567"
*/
}
｝
CheckAuthenticatorResponse( IN 0-to-256-unicode-char Password, IN 24-octet NtResponse, IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, IN 42-octet ReceivedResponse, OUT Boolean ResponseOK ) {
CheckAuthenticatorResponse（OUTブール、42オクテットReceivedResponseでは、0から256のunicode-文字のパスワードを24オクテットNtResponseでは、16オクテットPeerChallengeでは、16オクテットAuthenticatorChallengeでは、0から256のcharユーザーネームResponseOK）{
20-octet MyResponse
20オクテットMyResponse
set ResponseOK = FALSE GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, AuthenticatorChallenge, UserName, giving MyResponse)
ResponseOKを設定= FALSE GenerateAuthenticatorResponse（パスワード、NtResponse、PeerChallenge、AuthenticatorChallenge、ユーザ名、与えMyResponse）
if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE return ResponseOK }
IF（MyResponse = ReceivedResponse）を} ResponseOK = TRUEリターンResponseOKを設定します
datatype-PWBLOCK { 256-unicode-char Password 4-octets PasswordLength }
データ型-PWBLOCK {256ユニコード文字パスワード4オクテットPasswordLength}
NewPasswordEncryptedWithOldNtPasswordHash( IN 0-to-256-unicode-char NewPassword, IN 0-to-256-unicode-char OldPassword, OUT datatype-PWBLOCK EncryptedPwBlock ) { NtPasswordHash( OldPassword, giving PasswordHash )
{NtPasswordHash（OldPassword、PasswordHashを与える）（0から256ユニコード文字OldPassword、OUTデータ型-PWBLOCK EncryptedPwBlock IN 0対256ユニコード文字NEWPASSWORD、IN）NewPasswordEncryptedWithOldNtPasswordHash
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 ) {
（OUTデータ型-PWBLOCK PwBlock、16オクテットPasswordHash IN、0から256ユニコード文字パスワードIN）EncryptPwBlockWithPasswordHash {
Fill ClearPwBlock with random octet values
ランダムオクテット値でClearPwBlockを記入
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 ) }
PwSize = lstrlenW（パスワード）*はsizeof（ユニコード文字）PwOffset =はsizeof（ClearPwBlock.Password） - PwSize移動PwSizeオクテット（ClearPwBlock.Password + PwOffset）へのパスワードからClearPwBlock.PasswordLength = PwSize Rc4Encrypt（ClearPwBlock、はsizeof（ClearPwBlock） PasswordHash、はsizeof（PasswordHash）、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 ) }
{NtPasswordHash（OldPassword、OldPasswordHash与える）（NewPasswordHashを与えるNEWPASSWORD）NtPasswordHashをNtPasswordHashEncryptedWithBlock（OldPasswordHash（0対256ユニコード文字OldPassword、OUT 16オクテットEncryptedPasswordHash IN 0対256ユニコード文字NEWPASSWORD、IN）OldNtPasswordHashEncryptedWithNewNtPasswordHash 、NewPasswordHash、与えEncryptedPasswordHash）}
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（16オクテットIN PasswordHash、16オクテットのブロック、OUT 16オクテットサイファー）{DESENCRYPT（第8オクテットPasswordHash、第7オクテットブロック、与える第8オクテットサイファー）
DesEncrypt( 2nd 8-octets PasswordHash, 2nd 7-octets Block, giving 2nd 8-octets Cypher ) }
DESENCRYPT（2 8オクテットPasswordHash、2 7オクテットブロック、与え2 8オクテットサイファー）}
The following sections include protocol negotiation and hash generation examples.
以下のセクションでは、プロトコルネゴシエーションとハッシュ生成例を含みます。
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.
レスポンスの再試行は、パスワードの変更後に許されることはありません。パスワードの変更は、応答の再試行の後に発生する可能性があります。
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（レスポンス検証に成功した認証は、呼び出しが続きます）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
(Authenticator Response verification fails, peer disconnects)
（認証応答の検証が失敗し、ピア切断）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=0)
(Authenticator disconnects)
（認証の切断）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in failure message ->
<- Success/Authenticator Response
(Authenticator Response verification succeeds, call continues)
（レスポンス検証に成功した認証は、呼び出しが続きます）
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in Failure message ->
<- Failure (E=691 R=0)
<- Authenticator Challenge Peer Response/Challenge -> <- Failure (E=648 R=0 V=3), disable short timeout ChangePassword (++ID) to challenge in Failure message -> <- Success/Authenticator Response
< - 認証チャレンジピア応答/チャレンジ - > < - 失敗（E = 648、R = 0 V = 3）失敗メッセージに挑戦する、無効に短いタイムアウトのChangePassword（++ ID） - > < - 成功/認証応答
(Authenticator Response verification succeeds, call continues)
（レスポンス検証に成功した認証は、呼び出しが続きます）
<- Authenticator Challenge Peer Response/Challenge -> <- 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/Authenticator Response
< - 認証チャレンジピア応答/チャレンジ - > < - 最初のチャレンジに失敗（E = 691、R = 1）、無効短いタイムアウト応答（++ ID）+ 23 - > < - 失敗（E = 648、R = 0 V = > < - - 成功/認証応答2）、初挑戦+ 23に短いタイムアウトのChangePassword（++ ID）を無効
(Authenticator Response verification succeeds, call continues)
（レスポンス検証に成功した認証は、呼び出しが続きます）
Intermediate values for user name "User" and password "clientPass". All numeric values are hexadecimal.
ユーザー名「ユーザー」とパスワード「clientPass」の中間値。すべての数値は16進数です。
0-to-256-char UserName: 55 73 65 72
0から256文字のユーザー名：55 73 65 72
0-to-256-unicode-char Password: 63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
0から256ユニコード文字パスワード：63 00（c）00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00
16-octet AuthenticatorChallenge: 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28
16オクテットAuthenticatorChallenge：Khabbの頬感やや弱いの愛の巣S F P 6021のアモス決して決して裁判官
16-octet PeerChallenge: 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
16オクテットPeerChallenge：21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C〜7E
8-octet Challenge: D0 2E 43 86 BC E9 12 26
8オクテットチャレンジ：D0 2E 43 86 BC E9 12 26
16-octet PasswordHash: 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE
16オクテットPasswordHash：44 EB BA 8D 53 12 B8 D6 11 47 44 11 69 89 F5 AE
24 octet NT-Response: 82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
24オクテットNT-応答：82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF
16-octet PasswordHashHash: 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
16オクテットPasswordHashHash：41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
42-octet AuthenticatorResponse: "S=407A5589115FD0D6209F510FE9C04566932CDA56"
42オクテットAuthenticatorResponse： "S = 407A5589115FD0D6209F510FE9C04566932CDA56"
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 password "MyPw" to generate a pair of DES keys (e.g., for use in the NtPasswordHashEncryptedWithBlock() described in section 8.13).
DESは、パリティビットを挿入することによって64ビットに拡張56ビットキーを使用します。キーのパリティが固定された後、すべての8番目のビットは、パリティビットであり、各オクテット（1）に設定されるビットの数は奇数です。すなわち、奇数パリティ。多くのDESエンジンは単純にパリティビットを除去、しかし、パリティをチェックしないことに注意してください。次の例は、DES鍵のペアを生成するためのパスワード「MyPw」を使用した結果の値を示す（例えば、セクション8.13に記載NtPasswordHashEncryptedWithBlock（）で使用するため）。
0-to-256-unicode-char Password: 4D 79 50 77
0から256ユニコード文字パスワード：4D 79 50 77
16-octet PasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16オクテットPasswordHash：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
第二に、 "生" のDESキー（パスワードハッシュの第二の7つのオクテット）0E DD E3 33 7D 42 7F
Second parity-corrected DES key (eight octets): 0E 6E 79 67 37 EA 08 FE
第二にパリティ訂正DESキー（8つのオクテット）：0E 6E 79 67 37 EA 08 FE
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
実装の詳細としては、オーセンティケータは、ブルートフォースパスワード推測攻撃をより困難にするために許可され、パスワードの再試行の回数を制限する必要があります。
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1]シンプソン、W.、 "ポイントツーポイントプロトコル（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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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メッセージダイジェストアルゴリズム"、RFC 1320、1992年4月。
[6] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact:
[6] RC4は情報、接触のライセンスについては、RSAデータセキュリティ社からライセンスの下で利用可能な独自の暗号化アルゴリズムは次のとおりです。
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
[7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[7]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9.
[8] "Unicode規格、バージョン2.0"、ユニコードコンソーシアム、アディソン・ウェズリー、1996 ISBN 0-201-48345-9。
[9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[9]ソーン、G.とコブ、S.、 "マイクロソフトPPP CHAP拡張機能"、RFC 2433、1998年10月。
[10] "DES Modes of Operation", Federal Information Processing Standards Publication 81, National Institute of Standards and Technology, December 1980.
[10]「動作のDESモード」、連邦情報処理規格出版81、米国国立標準技術研究所、1980年12月。
[11] "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, National Institute of Standards and Technology, April 1995.
[11]、連邦情報処理規格180-1公報、米国国立標準技術研究所、1995年4月「ハッシュ標準セキュア」。
[12] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999.
[12]ソーン、G.、 "PPP LCP国際化設定オプション"、RFC 2484、1999年1月。
Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful suggestions and feedback.
便利な提案やフィードバックのためのブルース・ジョンソン、トニー・ベル、ポールリーチ、テレンススパイ、ダン・サイモン、ナレンドラGidwani、ガーディープ・シンポール、ジョディ・テリル、ブラッドRobel-フォレスト、そしてジョー・デイヴィスに（順不同）感謝します。
Questions about this memo can also be directed to:
このメモに関する質問も対象とすることができます。
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052
グレンツォルンマイクロソフト社1つのマイクロソフト道、レッドモンド、ワシントン98052
Phone: +1 425 703 1559 Fax: +1 425 936 7329 EMail: gwz@acm.org
電話：+1 425 703 1559ファックス：+1 425 936 7329 Eメール：gwz@acm.org
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。