RFC2759 日本語訳
2759 Microsoft PPP CHAP Extensions, Version 2. G. Zorn. January 2000. (Format: TXT=34178 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Zorn Request for Comments: 2759 Microsoft Corporation Category: Informational January 2000
コメントを求めるワーキンググループG.ゾルン要求をネットワークでつないでください: 2759年のマイクロソフト社カテゴリ: 情報の2000年1月
Microsoft PPP CHAP Extensions, Version 2
マイクロソフトpppやつ拡大、バージョン2
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するために広げることができるLink ControlプロトコルとNetwork Controlプロトコル(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.
このドキュメントはマイクロソフトのPPP CHAP方言(さん-CHAP-V2)のバージョンtwoについて説明します。 さん-CHAP-V2が同様ですが、非互換である、CHAPバージョンさん1 ([9])で説明されたさん-CHAP-V1。 特に、ある一定のプロトコル分野が削除されるか、再利用されますが、異なった意味論と共にありました。 さらに、さん-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.
様々なさん-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].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[3]で説明されるように解釈されることになっていてください、」であるべきです
Zorn Informational [Page 1] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[1ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 LCP構成. . . . . . . . . . . . . . . . . . . . . . . 3 3。 パケット. . . . . . . . . . . . . . . . . . . . . . . 3 4に挑戦してください。 応答パケット. . . . . . . . . . . . . . . . . . . . . . . . 4 5。 成功パケット. . . . . . . . . . . . . . . . . . . . . . . . 4 6。 失敗パケット. . . . . . . . . . . . . . . . . . . . . . . . 5 7。 変化パスワードパケット. . . . . . . . . . . . . . . . . . . . 6 8。 擬似コード. . . . . . . . . . . . . . . . . . . . . . . . . . 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。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1。 交渉の例. . . . . . . . . . . . . . . . . . . . 14 9.1の.1。 うまくいっている認証. . . . . . . . . . . . . . . . . 15 9.1.2。 固有識別文字認証失敗. . . . . . . . . . . 15 9.1.3。 再試行のない失敗した認証は.4に.159.1を許容しました。 再試行. . . . . . . . . . . 15 9.1.5の後のうまくいっている認証。 3つの試みによる攻撃が.159.1に.6を許容した失敗したハッキング。 パスワード変化. . . . . . 16 9.1.7があるうまくいっている認証。 再試行によるうまくいっている認証とパスワードは変化します。 . 16 9.2. 例. . . . . . . . . . . . . . . . . . . . . . . . 16 9.3を論じ尽くしてください。 DESキー生成. . . . . . . . . . . . . . . . 17 10に関する例。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 18 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 19 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 19 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 20
Zorn Informational [Page 2] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[2ページ]のRFC2759マイクロソフトやつV2 January 2000さん
1. Introduction
1. 序論
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:
可能であるところでは、さん-CHAP-V2がさん-CHAP-V1と標準のCHAPの両方と一致しています。 簡潔に、さん-CHAP-V2とCHAP-V1さんの違いは以下の通りです。
* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP
option 3, Authentication Protocol.
* さん-CHAP-V2は、LCPオプション3、AuthenticationプロトコルでCHAP Algorithm0x81を交渉することによって、有効にされます。
* 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.
* さん-CHAP-V2は、Responseパケットと固有識別文字応答のときにSuccessパケットの上で同輩挑戦を背負うことによって、互いの認証を同輩の間に提供します。
* 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.
* 同輩挑戦とユーザ名を含むようにResponseパケットのサブ分野の「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.
* さん-CHAP-V1では、Responseパケットでいつも「LANマネージャコンパチブルチャレンジレスポンス」サブ野原を送りました。 さん-CHAP-V2でこの野原をPeer-挑戦分野に取り替えました。
* The format of the Message field in the Failure packet has been
changed.
* FailureパケットのMessage分野の形式を変えました。
* 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.
* Change Password(バージョン1)とChange Password(バージョン2)パケットはもう支持されません。 それらを単一のChange-パスワードパケットに取り替えました。
2. LCP Configuration
2. LCP構成
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.
標準のCHAPに、さん-CHAP-V2のためのLCP構成がそれと同じである、Algorithm分野には値があるのを除いて、MD5よりむしろ0×81が0×05を評価します。 さん-CHAP-V2を支持しませんが、正しくLCP Config-レイを実行するPPP実現はこの標準的でないオプションに対処することにおける問題を全く持つべきではありません。
3. Challenge Packet
3. 挑戦パケット
The MS-CHAP-V2 Challenge packet is identical in format to the standard CHAP Challenge packet.
さん-CHAP-V2 Challengeパケットは形式が標準の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.
さん-CHAP-V2固有識別文字は16八重奏の挑戦Value野原を送ります。 同輩は16八重奏価値を選択するための写しマイクロソフトのアルゴリズムではなく、標準のガイドラインを必要とします。偶発性[1、2、7]SHOULDでは、守られてください。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
マイクロソフト固有識別文字は現在、Name分野に情報を提供しません。 これは将来、変化するかもしれません。
Zorn Informational [Page 3] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[3ページ]のRFC2759マイクロソフトやつV2 January 2000さん
4. Response Packet
4. 応答パケット
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:
さん-CHAP-V2 Responseパケットは形式が標準のCHAP Responseパケットと同じです。 しかしながら、Value分野は以下の通り異なってサブフォーマットされています:
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.
Peer-挑戦分野は16八重奏の乱数です。 名前が含意するように、それは、同輩によって発生して、下のNT-応答分野の計算に使用されます。 同輩は16八重奏の値を選択するための写しマイクロソフトのアルゴリズムではなく、標準のガイドラインを必要とします。偶発性[1、2、7]SHOULDでは、守られてください。
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).
通常のGenerateNTResponse()によって出力されるように、NT-応答分野は、パスワードのコード化された機能と、ユーザ名と、Peer-挑戦分野のコンテンツと容認された挑戦(以下でセクション8.1を見る)です。 Windows NTパスワードは(理論的に)256の大文字と小文字を区別するユニコード[8]キャラクタへの0のストリングです。 Windows NTの最新版は主に互換性理由でパスワードを14のキャラクタに制限します。 これは将来、変化するかもしれません。 NT-応答分野コンテンツを計算するとき、ユーザ名だけが少しも関連Windows NTドメイン名なしで使用されます。 Windows NTドメイン名が存在しているかどうかにかかわらずこれはName分野で本当です(以下を見てください)。
The Flag field is reserved for future use and MUST be zero.
Flag分野は、今後の使用のために予約されて、ゼロであるに違いありません。
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").
Name分野は同輩のユーザアカウント名を特定する(理論的に)256人の大文字と小文字を区別するASCII文字への0のストリングです。 Windows NTドメイン名はユーザのアカウント名(例えば、"BIGCO"がユーザアカウント"johndoe"を含むWindows NTドメインである「BIGCO\johndoe」)を前に置くかもしれません。 ドメインが提供していて、また、バックスラッシュが省略されるべきであるということでないなら、(例えば、"johndoe"。)です。
5. Success Packet
5. 成功パケット
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 Successパケットと同じです。 しかしながら、Message分野は42八重奏の固有識別文字応答ストリングと印刷可能なメッセージを含んでいます。 メッセージ分野の形式は以下で例証されます。
"S=<auth_string> M=<message>"
「<auth_ストリングS=>Mは<メッセージ>と等しいです」
Zorn Informational [Page 4] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[4ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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_ストリング>量は40の16進数字としてASCIIでコード化された20八重奏番号です。 16進数字A-F(存在しているなら)は大文字しているに違いありません。 通常のGenerateAuthenticatorResponse()によって出力されるように挑戦からChallengeパケット、ResponseパケットからのPeer-挑戦とNT-応答分野、および同輩パスワードからこの数を得ます(以下でセクション8.7を見てください)。 Successパケットが受け取られているとき、認証している同輩は固有識別文字応答について確かめなければなりません。 固有識別文字について確かめるための方法は下のセクション8.8で説明されます。 固有識別文字応答がなくなるか、または不正確であるなら、同輩はセッションを終わらせなければなりません。
The <message> quantity is human-readable text in the appropriate charset and language [12].
適切なcharsetと言語[12]で<メッセージ>量は人間読み込み可能なテキストです。
6. Failure Packet
6. 失敗パケット
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:
Failureパケットは形式が標準のCHAP Failureパケットと同じです。 しかしながら、標準のCHAP規則とは逆にプロトコルの操作に影響するMessage分野に格納されたフォーマット済みのテキストがあります。 Messageフィールド形式は以下の通りです。
"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 誤り_は_何ログオン_時間647もの満期の649誤り_いいえ、_DIALIN_許可691誤り_の誤り_ACCT_身体障害者648誤り_PASSWD_認証_故障709誤り_変化_パスワードを制限しました。
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'です。 固有識別文字が'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"は16進挑戦価値のASCII表現です。 この分野は、長い間のまさに32の八重奏でなければならなく、存在していなければなりません。
Zorn Informational [Page 5] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[5ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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進バージョンコード(10ケタである必要はない)のASCII表現です。さん-CHAP-V2に関して、これはいつもSHOULDを評価します。3になってください。
<msg> is human-readable text in the appropriate charset and
language [12].
適切なcharsetと言語[12]で<msg>は人間読み込み可能なテキストです。
7. Change-Password Packet
7. 変化パスワードパケット
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-パスワードパケットは標準のCHAPかさん-CHAP-V1のどちらかに現れません。 それで、同輩は前のResponseパケットで指定されたアカウントに関するパスワードを変えることができます。 固有識別文字がFailureパケットのMessage分野でERROR_PASSWD_EXPIRED(E=648)を報告する場合にだけ、Change-パスワードパケットを送るべきです。
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 NT4.0、Windows95、およびWindows 98の最近のバージョンによって支持されます。 それはWindows NT4.0、Windows95、およびWindows 98のWindows NT3.5、Windows NT3.51、または早めのバージョンによって支持されません。
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.
Identifierがさばく識別子は、合っている要求と回答で1つの八重奏と援助です。 値はこのパケットが応じる容認されたFailureパケットと1のIdentifierです。
Length
586
長さ586
Zorn Informational [Page 6] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[6ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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).
コード化されたパスワードThis分野は古いWindows NTパスワード細切れ肉料理でコード化された新しいWindows NTパスワードのPWBLOCKフォームを含んでいます、NewPasswordEncryptedWithOldNtPasswordHash()ルーチンで出力されるように(以下でセクション8.9を見てください)。
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).
Thisがさばくコード化された細切れ肉料理は新しいWindows NTパスワード細切れ肉料理でコード化された古いWindows NTパスワード細切れ肉料理を含んでいます、OldNtPasswordHashEncryptedWithNewNtPasswordHash()ルーチンで出力されるように(以下でセクション8.12を見てください)。
Peer-Challenge
A 16-octet random quantity, as described in the Response packet
description.
Responseパケット記述で説明されるようにA16八重奏の無作為の量に同輩と同じくらい挑戦してください。
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-応答分野(Responseパケット記述で説明されるように)の、しかし、新しいパスワードと挑戦のときに計算されたNT-応答はFailureパケットで受信されました。
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:
Thisがさばく旗は長さが2つの八重奏です。 少し、オプションの分野が0が16ビットの量の最下位ビットであるところで弛むということです。 この分野の形式は以下のダイヤグラムで例証されます:
1
5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-15Reserved、いつも(0)をクリアしてください。
8. Pseudocode
8. 擬似コード
The routines mentioned in the text above are described in pseudocode in the following sections.
上のテキストで言及されたルーチンは以下のセクションの擬似コードで説明されます。
8.1. GenerateNTResponse()
8.1. GenerateNTResponse()
GenerateNTResponse( IN 16-octet AuthenticatorChallenge, IN 16-octet PeerChallenge,
GenerateNTResponse、(16八重奏のAuthenticatorChallenge、16八重奏のPeerChallengeで
Zorn Informational [Page 7] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[7ページ]のRFC2759マイクロソフトやつV2 January 2000さん
IN 0-to-256-char UserName,
0〜256が焦げているユーザ名で
IN 0-to-256-unicode-char Password,
OUT 24-octet Response )
{
8-octet Challenge
16-octet PasswordHash
0が256ユニコードに焦げているINパスワード、出ている24八重奏の応答) 8八重奏の挑戦16八重奏のPasswordHash
ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName,
giving Challenge)
ChallengeHash(AuthenticatorChallenge、UserNameがChallengeに与えるPeerChallenge
NtPasswordHash( Password, giving PasswordHash )
ChallengeResponse( Challenge, PasswordHash, giving Response )
}
NtPasswordHash(PasswordHashに与えるパスワード)ChallengeResponse(挑戦、Responseに与えるPasswordHash)
8.2. ChallengeHash()
8.2. ChallengeHash()
ChallengeHash(
IN 16-octet PeerChallenge,
IN 16-octet AuthenticatorChallenge,
IN 0-to-256-char UserName,
OUT 8-octet Challenge
{
ChallengeHash、(8八重奏の挑戦からの16八重奏のAuthenticatorChallenge、0〜256が焦げているユーザ名のINの16八重奏のPeerChallenge
/*
* 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()、SHAUpdate()、およびSHAFinal()機能はSecure Hash Algorithm(SHA-1)[11]の*実現です。 これらは、公共の場で利用可能な*であるか*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()に入力されて、*というユーザ名(どんなprependedドメイン名も除きながら同輩と*によって提示されるように)だけが使用される/**。 */
SHAUpdate(Context, UserName, strlen(Username))
SHAFinal(Context, Digest)
memcpy(Challenge, Digest, 8)
}
SHAUpdate(文脈、ユーザ名は(ユーザ名)をstrlenする)SHAFinal(文脈、ダイジェスト)memcpy(挑戦、ダイジェスト、8)
Zorn Informational [Page 8] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[8ページ]のRFC2759マイクロソフトやつV2 January 2000さん
8.3. NtPasswordHash()
8.3. NtPasswordHash()
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.
*/
}
NtPasswordHash(0が256ユニコードに焦げているパスワードの出ている16八重奏のPasswordHash){ /**は、Password*をPasswordHashに逆転できないように論じ尽くすのにMD4アルゴリズム[5]を使用します。 0を終えながらいずれも含んでいて、パスワードだけが*なしで論じ尽くされます。 */ }
8.4. HashNtPasswordHash()
8.4. HashNtPasswordHash()
HashNtPasswordHash(
IN 16-octet PasswordHash,
OUT 16-octet PasswordHashHash )
{
/*
* Use the MD4 algorithm [5] to irreversibly hash
* PasswordHash into PasswordHashHash.
*/
}
HashNtPasswordHash(16八重奏のPasswordHashの出ている16八重奏のPasswordHashHash){ /**は、*PasswordHashをPasswordHashHashに逆転できないように論じ尽くすのにMD4アルゴリズム[5]を使用します。 */ }
8.5. ChallengeResponse()
8.5. ChallengeResponse()
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八重奏のChallenge、INの16八重奏のPasswordHashのOUTの24八重奏のResponse)、21の八重奏に無そっと歩いた状態でPasswordHashへのZPasswordHashを設定してください。
DesEncrypt( Challenge,
1st 7-octets of ZPasswordHash,
giving 1st 8-octets of Response )
DesEncrypt(挑戦、Responseの最初の8八重奏を与えるZPasswordHashの最初の7八重奏)
DesEncrypt( Challenge,
2nd 7-octets of ZPasswordHash,
giving 2nd 8-octets of Response )
DesEncrypt(挑戦、Responseの2番目の8八重奏を与えるZPasswordHashの2番目の7八重奏)
DesEncrypt( Challenge,
3rd 7-octets of ZPasswordHash,
giving 3rd 8-octets of Response )
}
DesEncrypt(挑戦、Responseの3番目の8八重奏を与えるZPasswordHashの3番目の7八重奏)
Zorn Informational [Page 9] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[9ページ]のRFC2759マイクロソフトやつV2 January 2000さん
8.6. DesEncrypt()
8.6. DesEncrypt()
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.
*/
}
DesEncrypt(8八重奏では、7八重奏の主要で、出ている8八重奏の暗号化でクリアしてください){ Cypherが使用できるだけであって、/**は、提供するのによるClearへの解読された後部がKeyであったならClearをCypherにコード化するのにECBモード[10]*にDES暗号化アルゴリズム[4]を使用します。 * DESアルゴリズムが入力として8番目、16番目と、24番目に、などビットが無視された*パリティビットであるところのそばで64ビットの*流れをみなすことに注意してください。コード化アルゴリズム。 * 同等なしで56ビットの入力*を受け入れるためにあなた自身のDESに書かないと、あなたは、自分でパリティビット*を挿入する必要があるでしょう。 */ }
8.7. GenerateAuthenticatorResponse()
8.7. GenerateAuthenticatorResponse()
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、16八重奏のAuthenticatorChallenge、0〜256が焦げているユーザ名の出ている42八重奏のAuthenticatorResponse)、16八重奏のPasswordHash16八重奏のPasswordHashHash8八重奏の挑戦
/*
* "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、0×61、0×67、0×69、0×63、0×20、0×73、0×65、0×72、0×76、0×65、0×72、0×20、0×74、0x6F、0×20、0×63、0x6C、0×69、0×65、0x6E、0×74、0×20、0×73、0×69、0×67、0x6E、0×69、0x6E、0×67、0×20、0×63、0x6F、0x6E、0×73、0×74、0×61、0x6E、0×74、。
Zorn Informational [Page 10] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[10ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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]は0×50、0×61、0×64、0×20、0×74、0x6F、0×20、0x6D、0×61、0x6B、0×65、0×20、0×69、0×74、0×20、0×64、0x6F、0×20、0x6D、0x6F、0×72、0×65、0×20、0×74、0×68、0×61、0x6E、0×20、0x6F、0x6E、0×65、0×20、0×69、0×74、0×65、0×72、0×61、0×74、0×69、0x6F、0x6Eと等しいです。
/*
* Hash the password with MD4
*/
MD4*/に従って、/**はパスワードを論じ尽くします。
NtPasswordHash( Password, giving PasswordHash )
NtPasswordHash(PasswordHashに与えるパスワード
/*
* Now hash the hash
*/
/**は現在、細切れ肉料理*/を論じ尽くします。
HashNtPasswordHash( PasswordHash, giving PasswordHashHash)
HashNtPasswordHash(PasswordHashHashに与えるPasswordHash
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(AuthenticatorChallenge、UserNameがChallengeに与えるPeerChallenge
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"
*/
/**は、「S=」が*40ASCII16進数字で続いて'ダイジェスト'の値をコード化して、*AuthenticatorResponseでそれを返します。 * 例えば、*"S=0123456789ABCDEF0123456789ABCDEF01234567"*/
}
}
Zorn Informational [Page 11] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[11ページ]のRFC2759マイクロソフトやつV2 January 2000さん
8.8. CheckAuthenticatorResponse()
8.8. CheckAuthenticatorResponse()
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(0が256ユニコードに焦げているパスワード、24八重奏のNtResponse、16八重奏のPeerChallenge、16八重奏のAuthenticatorChallenge、0〜256が焦げているユーザ名、42八重奏のReceivedResponseの出ているブールResponseOK)
20-octet MyResponse
20八重奏のMyResponse
set ResponseOK = FALSE
GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge,
AuthenticatorChallenge, UserName,
giving MyResponse)
ResponseOK=FALSE GenerateAuthenticatorResponseを設定してください。(NtResponse、PeerChallenge、AuthenticatorChallenge、UserNameがMyResponseに与えるパスワード
if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE
return ResponseOK
}
そして、(MyResponse=ReceivedResponse)はTRUEリターンResponseOK=ResponseOKを設定します。
8.9. NewPasswordEncryptedWithOldNtPasswordHash()
8.9. NewPasswordEncryptedWithOldNtPasswordHash()
datatype-PWBLOCK
{
256-unicode-char Password
4-octets PasswordLength
}
データ型式-PWBLOCK256ユニコードが焦げているパスワード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 )
NewPasswordEncryptedWithOldNtPasswordHash(0が256ユニコードに焦げているNewPassword、0が256ユニコードに焦げているOldPasswordの出ているデータ型式-PWBLOCK EncryptedPwBlock)、NtPasswordHash(PasswordHashに与えるOldPassword
EncryptPwBlockWithPasswordHash( NewPassword,
PasswordHash,
giving EncryptedPwBlock )
}
EncryptPwBlockWithPasswordHash(NewPassword、EncryptedPwBlockに与えるPasswordHash)
Zorn Informational [Page 12] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[12ページ]のRFC2759マイクロソフトやつV2 January 2000さん
8.10. EncryptPwBlockWithPasswordHash()
8.10. EncryptPwBlockWithPasswordHash()
EncryptPwBlockWithPasswordHash(
IN 0-to-256-unicode-char Password,
IN 16-octet PasswordHash,
OUT datatype-PWBLOCK PwBlock )
{
EncryptPwBlockWithPasswordHash(0が256ユニコードに焦げているパスワード、16八重奏のPasswordHashの出ているデータ型式-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 )
}
PwSize=lstrlenW(パスワード)*sizeof(ユニコード炭)PwOffsetはsizeof(ClearPwBlock.Password)と等しいです--Password ClearPwBlock.PasswordLengthからの(ClearPwBlock.Password+PwOffset)へのPwSize Move PwSize八重奏はPwSize Rc4Encryptと等しいです(ClearPwBlock、sizeof(ClearPwBlock)、PasswordHash、sizeof(PasswordHash)がPwBlockに与えて)。
8.11. Rc4Encrypt()
8.11. Rc4Encrypt()
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.
*/
}
Rc4Encrypt(IN x-八重奏Clear、IN整数ClearLength、IN y-八重奏Key、IN整数KeyLength OUT x-八重奏Cypher){ /**は、*長さのKeyLength八重奏のKeyを提供することによってClear*にCypherを解読して戻すことができるだけであるように*長さClearLength八重奏のClearを同じ長さのCypherにコード化するのにRC4暗号化アルゴリズム[6]を使用します。 */ }
Zorn Informational [Page 13] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[13ページ]のRFC2759マイクロソフトやつV2 January 2000さん
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash()
8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash()
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 )
}
OldNtPasswordHashEncryptedWithNewNtPasswordHash(0が256ユニコードに焦げているNewPassword、0が256ユニコードに焦げているOldPasswordの出ている16八重奏のEncryptedPasswordHash)NtPasswordHash(OldPasswordHashに与えるOldPassword)NtPasswordHash(NewPasswordHashに与えるNewPassword)NtPasswordHashEncryptedWithBlock(OldPasswordHash、EncryptedPasswordHashに与えるNewPasswordHash)
8.13. NtPasswordHashEncryptedWithBlock()
8.13. NtPasswordHashEncryptedWithBlock()
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八重奏のPasswordHash、16八重奏のブロックでの出ている16八重奏の暗号化)、DesEncrypt(最初の8八重奏のPasswordHash、最初の8八重奏のCypherに与える最初の7八重奏のBlock)
DesEncrypt( 2nd 8-octets PasswordHash,
2nd 7-octets Block,
giving 2nd 8-octets Cypher )
}
DesEncrypt(第2 8八重奏のPasswordHash、第2 8八重奏のCypherに与える第2 7八重奏のBlock)
9. Examples
9. 例
The following sections include protocol negotiation and hash generation examples.
以下のセクションは議定書交渉と細切れ肉料理世代の例を含んでいます。
9.1. Negotiation Examples
9.1. 交渉の例
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.
応答再試行はChange Passwordの後に決して許されていません。 変化Passwordは応答再試行の後に起こるかもしれません。
Zorn Informational [Page 14] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[14ページ]のRFC2759マイクロソフトやつV2 January 2000さん
9.1.1. Successful authentication
9.1.1. うまくいっている認証
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
<固有識別文字挑戦同輩挑戦->応答/<成功/固有識別文字応答
(Authenticator Response verification succeeds, call continues)
(呼び出しは、固有識別文字Response検証が成功し続けています)
9.1.2. Authenticator authentication failure
9.1.2. 固有識別文字認証失敗
<- Authenticator Challenge
Peer Response/Challenge ->
<- Success/Authenticator Response
<固有識別文字挑戦同輩挑戦->応答/<成功/固有識別文字応答
(Authenticator Response verification fails, peer disconnects)
(検証が失敗する固有識別文字Response、同輩分離)
9.1.3. Failed authentication with no retry allowed
9.1.3. 再試行が全く許されていない失敗した認証
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=0)
<固有識別文字挑戦同輩応答/挑戦-><失敗(691E=R=0)
(Authenticator disconnects)
(固有識別文字分離)
9.1.4. Successful authentication after retry
9.1.4. 再試行の後のうまくいっている認証
<- Authenticator Challenge
Peer Response/Challenge ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to challenge in failure message ->
<- Success/Authenticator Response
<固有識別文字Challenge Peer Response/は-><失敗に挑戦して(Eは691R=1と等しいです)、失敗メッセージ-><成功/固有識別文字Responseで挑戦する(+ + ID)を短いタイムアウトResponseに無効にしてください。
(Authenticator Response verification succeeds, call continues)
(呼び出しは、固有識別文字Response検証が成功し続けています)
9.1.5. Failed hack attack with 3 attempts allowed
9.1.5. 3つの試みが許されている失敗したハッキング攻撃
<- 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)
<固有識別文字Challenge Peer Response/は-><失敗に挑戦して(Eは691R=1と等しいです)、Failureメッセージ-><失敗で挑戦するためにFailureメッセージ-><失敗(Eは691R=1と等しい)で挑戦して、短いタイムアウトResponse(+ + ID)であると無効にする(+ + ID)を短いタイムアウトResponseに無効にしてください。(691E=R=0)
Zorn Informational [Page 15] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[15ページ]のRFC2759マイクロソフトやつV2 January 2000さん
9.1.6. Successful authentication with password change
9.1.6. パスワード変化に伴ううまくいっている認証
<- 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
<固有識別文字Challenge Peer Response/は-><失敗に挑戦して(Eは648R=0 V=3と等しいです)、Failureメッセージ-><成功/固有識別文字Responseで挑戦する(+ + ID)を短いタイムアウトChangePasswordに無効にしてください。
(Authenticator Response verification succeeds, call continues)
(呼び出しは、固有識別文字Response検証が成功し続けています)
9.1.7. Successful authentication with retry and password change
9.1.7. 再試行とパスワード変化に伴ううまくいっている認証
<- 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
<固有識別文字Challenge Peer Response/は-><失敗に挑戦して(Eは691R=1と等しいです)、短いタイムアウトがResponse(+ + ID)であると最初の挑戦+23-><の故障(Eは648R=0 V=2と等しい)に無効にしてください、そして、短いタイムアウトがChangePassword(+ + ID)であることを最初に、挑戦+23-><成功/固有識別文字Responseに無効にしてください。
(Authenticator Response verification succeeds, call continues)
(呼び出しは、固有識別文字Response検証が成功し続けています)
9.2. Hash Example
9.2. ハッシュの例
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 6C00 69 00 65 00 6E00 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: 5B 5D7C7D 7B3F2F3 3EのC2C60 21 32 26 26 28
16-octet PeerChallenge: 21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E
16八重奏のPeerChallenge: 7 21 40 23 24 25 5 26Eの2A28 29 5F2B 3A33 7C E
8-octet Challenge: D0 2E 43 86 BC E9 12 26
8八重奏の挑戦: D0 2E紀元前43 86年Eの9 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 Ba8D53 12B8 D6 11 47 44 11F5 69 89AE
Zorn Informational [Page 16] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[16ページ]のRFC2759マイクロソフトやつV2 January 2000さん
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のCD8D70 8B5E A0 8F AA39 81CD83 54 42 33 11 4A3D85D6 DF
16-octet PasswordHashHash: 41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F
16八重奏のPasswordHashHash: 41 C0 0C58 4B D2 D9 1C40 17A2 A1 2F A5 9F3F
42-octet AuthenticatorResponse: "S=407A5589115FD0D6209F510FE9C04566932CDA56"
42八重奏のAuthenticatorResponse: "S=407A5589115FD0D6209F510FE9C04566932CDA56""
9.3. Example of DES Key Generation
9.3. DESキー生成に関する例
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エンジンが単にパリティビットを剥取りながら同等をチェックしないことに注意してください。 以下の例は、1組のDESキー(例えば、セクション8.13で説明されたNtPasswordHashEncryptedWithBlock()における使用のための)を生成するために"MyPw"というパスワードの使用から生じる値を例証します。
0-to-256-unicode-char Password: 4D 79 50 77
0が256ユニコードに焦げているパスワード: 4D79 50 77
16-octet PasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16八重奏のPasswordHash: 4FC15 6A F7エドCD6C0E DD E3 33 7D42 7F Eの西暦
First "raw" DES key (initial 7 octets of password hash): FC 15 6A F7 ED CD 6C
最初の「生」のDESキー(パスワードハッシュの初期の7つの八重奏): FC15 6A F7エドCD6C
First parity-corrected DES key (eight octets): FD 0B 5B 5E 7F 6E 34 D9
最初の同等で直っているDESキー(8つの八重奏): FD 0B 5B5 7EのF6E34D9
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 7D42 7F
Second parity-corrected DES key (eight octets): 0E 6E 79 67 37 EA 08 FE
2番目の同等で直っているDESキー(8つの八重奏): 0E6E79 67 37EA08FE
10. Security Considerations
10. セキュリティ問題
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
実装の詳細として、固有識別文字SHOULDはブルートフォースパスワード推測攻撃をより難しくすることができたパスワード再試行の数を制限します。
Zorn Informational [Page 17] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[17ページ]のRFC2759マイクロソフトやつV2 January 2000さん
11. References
11. 参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[1] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[2] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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メッセージダイジェストアルゴリズム」、RFC1320、4月1992日
[6] RC4 is a proprietary encryption algorithm available under
license from RSA Data Security Inc. For licensing information,
contact:
[6] RC4は情報、接触を認可するRSA Data Security株式会社Forからライセンスの下で利用可能な独占暗号化アルゴリズムです:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
海洋のParkwayレッドウッドシティー、RSA Data Security Inc.100カリフォルニア94065-1031
[7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[7] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[8] "The Unicode Standard, Version 2.0", The Unicode Consortium,
Addison-Wesley, 1996. ISBN 0-201-48345-9.
[8] 「ユニコード規格、バージョン2インチ、ユニコード共同体、アディソン-ウエスリー、1996。」 ISBN0-201-48345-9。
[9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC
2433, October 1998.
[9] ゾルンとG.とコッブ、S.、「マイクロソフトpppやつ拡大」、RFC2433、1998年10月。
[10] "DES Modes of Operation", Federal Information Processing
Standards Publication 81, National Institute of Standards and
Technology, December 1980.
[10]「DES運転モード」、連邦政府の情報処理規格公表81、米国商務省標準技術局、12月1980日
[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国際化設定オプション」、RFC2484、1999年1月。
Zorn Informational [Page 18] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[18ページ]のRFC2759マイクロソフトやつV2 January 2000さん
12. Acknowledgements
12. 承認
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.
役に立つ提案とフィードバックをブルース・ジョンソン、トニー・ベル、ポール・リーチ、テレンス・シュピース、ダン・サイモン、Narendra Gidwani、GurdeepシンPall、ジョディー・テリル、ブラッド・Robel-フォレスト、およびジョー・デイヴィースをありがとうございます(特に決まった順番でなく)。
13. Author's Address
13. 作者のアドレス
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、1559Fax: +1 7329年の425 936メール: gwz@acm.org
Zorn Informational [Page 19] RFC 2759 Microsoft MS-CHAP-V2 January 2000
ゾルン情報[19ページ]のRFC2759マイクロソフトやつV2 January 2000さん
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Zorn Informational [Page 20]
ゾルンInformationalです。[20ページ]
一覧
スポンサーリンク
