[要約] RFC 2759は、Microsoft PPP CHAP拡張のバージョン2に関する仕様です。このRFCの目的は、PPP接続での認証プロセスを強化し、セキュリティを向上させることです。
Network Working Group G. Zorn
Request for Comments: 2759 Microsoft Corporation
Category: Informational January 2000
Microsoft PPP CHAP Extensions, Version 2
Microsoft PPP Chap Extensions、バージョン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.
Copyright（c）The Internet Society（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は、異なるネットワーク層プロトコルを確立および構成するための拡張可能なリンク制御プロトコルとネットワーク制御プロトコルファミリー（NCPS）を定義します。
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（MS-Chap-V1、[9]に記載されている）に似ていますが、互換性がありません。特に、特定のプロトコルフィールドは削除または再利用されていますが、セマンティクスが異なります。さらに、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.
さまざまなMS-Chap-V2プロトコルフィールドの生成で使用されるアルゴリズムは、セクション8で説明されています。交渉とハッシュ生成の例はセクション9に記載されています。
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].
このドキュメントでは、キーワードは「可能性があります」、「必要はありません」、「オプション」、「推奨」、「必要」、「必要はありません」は、[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 Compatible Challenge Response」サブフィールドが常に応答パケットに送信されました。このフィールドは、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）パケットはサポートされなくなりました。それらは、単一のChange-Passwordパケットに置き換えられました。
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のLCP構成と同一です。MS-Chap-V2をサポートしていないが、LCP Config-REJを正しく実装するPPP実装では、この非標準オプションに対処するのに問題はないはずです。
The MS-CHAP-V2 Challenge packet is identical in format to the standard CHAP Challenge packet.
MS-Chap-V2チャレンジパケットは、標準のChap Challengeパケットと同じ形式です。
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 Authenticatorsは、16-OCTETチャレンジバリューフィールドを送信します。ピアは、16オクテットの値を選択するためにMicrosoftのアルゴリズムを複製する必要はありませんが、ランダム性に関する標準的なガイドライン[1,2,7]を観察する必要があります。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
Microsoft Authenticatorsは現在、名前フィールドに情報を提供していません。これは将来変化する可能性があります。
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パスワードは、0〜（理論的に）256のケースセンシティブユニコード[8]文字の文字列です。Windows NTの現在のバージョンは、主に互換性の理由により、パスワードを14文字に制限しています。これは将来変化する可能性があります。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").
名前フィールドは、ピアのユーザーアカウント名を識別する0〜（理論的に）256のケースに敏感なASCII文字の文字列です。Windows NTドメイン名は、ユーザーのアカウント名（たとえば、「Bigco \ Johndoe」で、「Bigco」がユーザーアカウント「Johndoe」を含むWindows NTドメインです）に接頭する場合があります。ドメインが提供されていない場合、バックスラッシュも省略する必要があります（例：「ジョンドー」）。
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.
サクセスパケットは、標準のChap Successパケットと形式が同じです。ただし、メッセージフィールドには、42-OCTET認証応答文字列と印刷可能なメッセージが含まれています。メッセージフィールドの形式を以下に示します。
"S=<auth_string> M=<message>" 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.
"s = <auth_string> m = <message>" <auth_string>数量は、40ヘクサデシメル桁としてASCIIでエンコードされた20オクテット数です。16進数桁A-F（存在する場合）は大文字でなければなりません。この数値は、チャレンジパケット、ピアチャレンジ、および応答パケットからのNT応答フィールド、およびルーチンGenerateAuthenticAtorresponse（）による出力としてのピアパスワードからのチャレンジ（）から派生しています（以下のセクション8.7を参照）。認証ピアは、成功パケットを受信したときに認証装置の応答を確認する必要があります。認証器を検証する方法については、以下のセクション8.8で説明します。Authenticatorの応答が欠落または正しくない場合、ピアはセッションを終了する必要があります。
The <message> quantity is human-readable text in the appropriate charset and language [12].
<メッセージ>数量は、適切なcharsetと言語の人間が読みやすいテキストです[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>"
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進エラーコードのASCII表現（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_PERISTION 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」に設定されたASCIIフラグと、そうでない場合は「0」です。Authenticatorがこのフラグを「1」に設定すると、短いタイムアウトを無効にし、ピアがユーザーに新しい資格情報を促し、応答を再送信することを期待します。
The "cccccccccccccccccccccccccccccccc" is the ASCII representation of a hexadecimal challenge value. This field MUST be exactly 32 octets long and MUST be present.
「CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC」は、16進チャレンジ値の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」は、サーバーでサポートされているパスワードの変更プロトコルバージョンを示す小数バージョンコード（10桁ではない）のASCII表現です。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.
Change-Passwordパケットは、標準のCHAPまたはMS-Chap-V1のいずれにも表示されません。これにより、ピアは、前の応答パケットで指定されたアカウントのパスワードを変更できます。Change-Passwordパケットは、Authenticatorが故障パケットのメッセージフィールドに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 4.0、Windows 95、およびWindows 98の最近のバージョンでサポートされています。WindowsNT3.5、Windows NT 3.51、または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つのオクテットであり、リクエストと返信のマッチングに役立ちます。値は、このパケットが応答する受信した障害パケットの識別子です。
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).
暗号化されたパスワードこのフィールドには、古い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).
暗号化されたハッシュこのフィールドには、古い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応答フィールド（応答パケット説明で説明されているように）が、新しいパスワードと障害パケットで受信された課題で計算されます。
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,
IN 0-to-256-char UserName,
IN 0-to-256-unicode-char Password, OUT 24-octet Response ) { 8-octet Challenge 16-octet PasswordHash
0〜256-Unicode-charパスワード、24-OCTET応答）{8-OCTETチャレンジ16-OCTET PasswordHash
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge)
ChallengeHash（PeerChallenge、AuthenticatorChallenge、ユーザー名、課題を与える）
NtPasswordHash( Password, giving PasswordHash ) ChallengeResponse( Challenge, PasswordHash, giving Response ) }
ntpasswordhash（パスワード、passwordhashhashを与える）Challengeresponse（課題、パスワードハッシュ、応答を与える）}
ChallengeHash(
IN 16-octet PeerChallenge,
IN 16-octet AuthenticatorChallenge,
IN 0-to-256-char UserName,
OUT 8-octet Challenge
{
/*
* 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（Context）Shaupdate（Context、PeerChallenge、16）Shaupdate（Context、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（username））shafinal（context、digest）memcpy（challenge、digest、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
Challengeresponse（8-OCTET Challenge、16-OCTET PasswordHash、24-OCTET Response）
DesEncrypt( Challenge, 1st 7-octets of ZPasswordHash, giving 1st 8-octets of Response )
desencrypt（チャレンジ、Zpasswordhashの1番目の7オクテット、応答の1番目の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番目の課題、3番目のZpasswordhash、3番目の8オクテットの応答）}
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
/*
* "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、0x74e、0x69、0x65、0x69、0x69、0x650x20、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、0x65、0x65、0x650x20、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（Context）Shaupdate（Context、PasswordHashhash、16）Shaupdate（Context、Ntresponse、24）Shaupdate（Context、Magic1、39）Shafinal（Context、Digest）
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（Context）Shaupdate（Context、Digest、20）Shaupdate（Context、Challenge、8）Shaupdate（Context、Magic2、41）Shafinal（Context、Digest）
/*
* 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 )
{
20-octet MyResponse
20-OCTET myResponse
set ResponseOK = FALSE GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, AuthenticatorChallenge, UserName, giving MyResponse)
set responseok = false generateauthenticatorresponse（パスワード、ntresponse、peerchallenge、authenticatorchallenge、username、vising myResponse）
if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE return ResponseOK }
if（myResponse = receceResponse）からresponseok = true return responseok}を設定}
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（0〜256-Unicode-char newPassword、0〜256-unicode-chhar oldpassword、out datatype-pwblock necryptedpwblock）
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, giving EncryptedPwBlock ) }
encryptpwblockwithpasswordhash（newpassword、passwordhash、giving necryptedpwblock）}
EncryptPwBlockWithPasswordHash( IN 0-to-256-unicode-char Password, IN 16-octet PasswordHash, OUT datatype-PWBLOCK PwBlock ) {
encryptpwblockwithpasswordhash（0〜256-Unicode-charパスワード、16-OCTET PasswordHash、out datatype-pwblock pwblock）{
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 )
}
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 )
}
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オクテットパスワードハッシュ、16オクテットブロック、16オクテットのサイファーで）{desencrypt（1番目の8-OCTET PasswordHash、1st 7-OCTETブロック、1番目の8オクテットCypherを提供）
DesEncrypt( 2nd 8-octets PasswordHash, 2nd 7-octets Block, giving 2nd 8-octets Cypher ) }
DesenCrypt（2nd 8-OCTETS PasswordHash、2nd 7-OCTETSブロック、2番目の8-OCTETS CYPHERを与える）}
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
(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
(Authenticator Response verification succeeds, call continues)
（認証者の応答の確認が成功し、コールが続きます）
Intermediate values for user name "User" and password "clientPass". All numeric values are hexadecimal.
ユーザー名「ユーザー」とパスワード「クライアントパス」の中間値。すべての数値は16進数です。
0-to-256-char UserName: 55 73 65 72
0〜256-CHARユーザー名：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-Unicode-charパスワード：63 00 6c 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-OCTET AuthenticatorChallenge：5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 28
16-octet PeerChallenge: 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
16-OCTET 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-OCTETチャレンジ：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 AE24 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
16-OCTET PasswordHash：44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 24 OCTET NT-Response：82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A3d 85 d6 df
16-octet PasswordHashHash: 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
16-OCTET PasswordHashhash：41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
42-octet AuthenticatorResponse: "S=407A5589115FD0D6209F510FE9C04566932CDA56"
42-OCTET Authenticator Response： "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は56ビットキーを使用し、パリティビットの挿入により64ビットに拡張されます。キーのパリティが修正された後、すべての8番目のビットはパリティビットであり、各オクテットに設定されたビットの数は奇妙です。すなわち、奇妙なパリティ。多くのDESエンジンはパリティをチェックしていないことに注意してください。ただし、単にパリティビットを剥がします。次の例は、DESキーのペアを生成するためのパスワード「MyPW」の使用から生じる値を示しています（たとえば、セクション8.13で説明したntpasswordhashencryptedwithblock（）で使用）。
0-to-256-unicode-char Password: 4D 79 50 77
0〜256-Unicode-charパスワード：4d 79 50 77
16-octet PasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16-OCTET 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
最初の "raw" des key（パスワードハッシュの初期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番目の "raw" des key（パスワードハッシュのセカンド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
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
実装の詳細として、Authenticatorは、Brute-Forceパスワードの推測攻撃をより困難にすることが許可されているパスワード再試行の数を制限する必要があります。
[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] 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] 「Data Encryption Standard（DES）」、Federal Information Standard Publication 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 Data Security Inc.からライセンス情報のライセンス情報のために利用可能な独自の暗号化アルゴリズムです。お問い合わせください。
RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
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] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium, Addison-Wesley, 1996. ISBN 0-201-48345-9.
[8] 「Unicode Standard、バージョン2.0」、Unicode Consortium、Addison-Wesley、1996。ISBN0-201-48345-9。
[9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[9] Zorn、G。およびCobb、S。、「Microsoft PPP Chap Extensions」、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 Modes of Operation」、Federal Information Standards Publication 81、国立標準技術研究所、1980年12月。
[11] "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, National Institute of Standards and Technology, April 1995.
[11] 「Secure Hash Standard」、Federal Information Standards Publication 180-1、国立標準技術研究所、1995年4月。
[12] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999.
[12] Zorn、G。、「PPP LCP Internationalization Configuration Option」、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.
ブルース・ジョンソン、トニー・ベル、ポール・リーチ、テレンス・スパイズ、ダン・サイモン、ナレンドラ・ギドワニ、ガーデープ・シン・ポール、ジョディ・テリル、ブラッド・ロベル・フォレスト、ジョー・デイヴィスの有用な提案とフィードバックに感謝します。
Questions about this memo can also be directed to:
このメモに関する質問は、次のように送信することもできます。
Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052
Glen Zorn Microsoft Corporation One Microsoft Way Redmond、Washington 98052
Phone: +1 425 703 1559
Fax: +1 425 936 7329
EMail: gwz@acm.org
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。