RFC2433 日本語訳
2433 Microsoft PPP CHAP Extensions. G. Zorn, S. Cobb. October 1998. (Format: TXT=34502 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Zorn
Request for Comments: 2433 S. Cobb
Category: Informational Microsoft Corporation
October 1998
コメントを求めるワーキンググループG.ゾルン要求をネットワークでつないでください: 2433秒間コッブCategory: 情報のマイクロソフト社1998年10月
Microsoft PPP CHAP Extensions
マイクロソフトpppやつ拡大
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
IESG Note
IESG注意
The protocol described here has significant vulnerabilities. People planning on implementing or using this protocol should read section 12, "Security Considerations".
ここで説明されたプロトコルは重要な脆弱性を持っています。 このプロトコルを実装するか、または使用するのを計画する人々は、セクション12、「セキュリティ問題」を読むべきです。
1. Abstract
1. 要約
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 Microsoft's PPP CHAP dialect (MS-CHAP), which extends the user authentication functionality provided on Windows networks to remote workstations. MS-CHAP is closely derived from the PPP Challenge Handshake Authentication Protocol described in RFC 1994 [2], which the reader should have at hand.
このドキュメントはマイクロソフトのPPP CHAP方言(さん-CHAP)を説明します。(それは、Windowsネットワークで遠隔ワークステーションに提供されたユーザー認証の機能性を広げます)。 読者が手元に持つべきであるRFC1994[2]で説明されたPPPチャレンジハンドシェイク式認証プロトコルからさん-CHAPを密接に得ます。
The algorithms used in the generation of various MS-CHAP protocol fields are described in an appendix.
様々なさん-CHAPプロトコル分野の世代に使用されるアルゴリズムは付録で説明されます。
2. Introduction
2. 序論
Microsoft created MS-CHAP to authenticate remote Windows workstations, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks.
マイクロソフトはリモートWindowsワークステーションを認証するためにさん-CHAPを作成しました、LANベースのユーザが暗号化を統合して、Windowsネットワークで使用されるアルゴリズムを論じ尽くす間に慣れている機能性を提供して。
Zorn & Cobb Informational [Page 1] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[1ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Where possible, MS-CHAP is consistent with standard CHAP. Briefly, the differences between MS-CHAP and standard CHAP are:
可能であるところでは、さん-CHAPが標準のCHAPと一致しています。 簡潔に、さん-CHAPと標準のCHAPの違いは以下の通りです。
* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP
option 3, Authentication Protocol.
* さん-CHAPは、LCPオプション3、AuthenticationプロトコルでCHAP Algorithm0x80を交渉することによって、有効にされます。
* The MS-CHAP Response packet is in a format designed for
compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and
Windows95 networking products. The MS-CHAP format does not
require the authenticator to store a clear-text or reversibly
encrypted password.
* マイクロソフトのWindows NT3.5、3.51、および4.0、およびWindows95ネットワーク製品との互換性のために設計された形式にはさん-CHAP Responseパケットがあります。 さん-CHAP形式は、クリアテキストかreversibly暗号化されたパスワードを保存するために固有識別文字を必要としません。
* MS-CHAP provides authenticator-controlled authentication retry
and password changing mechanisms.
* さん-CHAPは固有識別文字で制御された認証再試行とパスワード変化メカニズムを提供します。
* MS-CHAP defines a set of reason-for-failure codes returned in
the Failure packet Message field.
* さん-CHAPはFailureパケットMessage分野で返された1セットの失敗の理由コードを定義します。
3. Specification of Requirements
3. 要件の仕様
In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2].
そして、このドキュメント、「5月」というキーワードで「必須、「必須NOT」、「任意」の、そして、「お勧め」の“SHOULD"、「」、[2]で説明されるように解釈されることになっていてください、」であるべきです
4. LCP Configuration
4. LCP構成
The LCP configuration for MS-CHAP is identical to that for standard CHAP, except that the Algorithm field has value 0x80, rather than the MD5 value 0x05. PPP implementations which do not support MS-CHAP, but correctly implement LCP Config-Rej, should have no problem dealing with this non-standard option.
標準のCHAPに、さん-CHAPのためのLCP構成がそれと同じである、Algorithm分野には値があるのを除いて、MD5よりむしろ0×80が0×05を評価します。 さん-CHAPをサポートしませんが、正しくLCP Config-レイを実装するPPP実装はこの標準的でないオプションに対処することにおける問題を全く持つべきではありません。
5. Challenge Packet
5. 挑戦パケット
The MS-CHAP Challenge packet is identical in format to the standard CHAP Challenge packet.
さん-CHAP Challengeパケットは形式が標準のCHAP Challengeパケットと同じです。
MS-CHAP authenticators send an 8-octet challenge Value field. Peers need not duplicate Microsoft's algorithm for selecting the 8-octet value, but the standard guidelines on randomness [1,2,7] SHOULD be observed.
さん-CHAP固有識別文字は8八重奏の挑戦Value野原を送ります。 同輩は8八重奏の値を選択するための写しマイクロソフトのアルゴリズムではなく、標準のガイドラインを必要とします。偶発性[1、2、7]SHOULDでは、守られてください。
Microsoft authenticators do not currently provide information in the Name field. This may change in the future.
マイクロソフト固有識別文字は現在、Name分野に情報を提供しません。 これは将来、変化するかもしれません。
Zorn & Cobb Informational [Page 2] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[2ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
6. Response Packet
6. 応答パケット
The MS-CHAP Response packet is identical in format to the standard CHAP Response packet. However, the Value field is sub-formatted differently as follows:
さん-CHAP Responseパケットは形式が標準のCHAP Responseパケットと同じです。 しかしながら、Value分野は以下の通り異なってサブフォーマットされています:
24 octets: LAN Manager compatible challenge response
24 octets: Windows NT compatible challenge response
1 octet : "Use Windows NT compatible challenge response" flag
24の八重奏: LANマネージャコンパチブルチャレンジレスポンス24八重奏: Windows NTコンパチブルチャレンジレスポンス1八重奏: 「Windows NTコンパチブルチャレンジレスポンスを使用してください」という旗
The LAN Manager compatible challenge response is an encoded function of the password and the received challenge as output by the routine LmChallengeResponse() (see section A.1, below). LAN Manager passwords are limited to 14 case-insensitive OEM characters. Note that use of the LAN Manager compatible challenge response has been deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be zero-filled. The algorithm used in the generation of the LAN Manager compatible challenge response is described here for informational purposes only.
通常のLmChallengeResponse()によって出力されるように、LANマネージャコンパチブルチャレンジレスポンスは、パスワードのコード化された機能と容認された挑戦(以下のセクションA.1を見る)です。 LANマネージャパスワードは14の大文字と小文字を区別しないOEMキャラクタに制限されます。 LANマネージャコンパチブルチャレンジレスポンスの使用が推奨しないことに注意してください。 無いっぱいにされて、SHOULD NOTがそれ、およびサブ分野SHOULDを生成する同輩。 LANマネージャコンパチブルチャレンジレスポンスの世代に使用されるアルゴリズムは情報の目的だけのためにここで説明されます。
The Windows NT compatible challenge response is an encoded function of the password and the received challenge as output by the routine NTChallengeResponse() (see section A.5, below). The Windows NT password is a string of 0 to (theoretically) 256 case-sensitive Unicode [8] characters. Current versions of Windows NT limit passwords to 14 characters, mainly for compatibility reasons; this may change in the future.
通常のNTChallengeResponse()によって出力されるように、Windows NTコンパチブルチャレンジレスポンスは、パスワードのコード化された機能と容認された挑戦(以下のセクションA.5を見る)です。 Windows NTパスワードは(理論的に)256の大文字と小文字を区別するユニコード[8]キャラクタへの0のストリングです。 Windows NTの最新版は主に互換性理由でパスワードを14のキャラクタに制限します。 これは将来、変化するかもしれません。
The "use Windows NT compatible challenge response" flag, if 1, indicates that the Windows NT response is provided and should be used in preference to the LAN Manager response. The LAN Manager response will still be used if the account does not have a Windows NT password hash, e.g. if the password has not been changed since the account was uploaded from a LAN Manager 2.x account database. If the flag is 0, the Windows NT response is ignored and the LAN Manager response is used. Since the use of LAN Manager authentication has been deprecated, this flag SHOULD always be set (1) and the LAN Manager compatible challenge response field SHOULD be zero-filled.
「Windows NTコンパチブルチャレンジレスポンスを使用してください」という旗は、1であるならWindows NT応答が提供されて、LANマネージャ応答に優先して使用されるべきであるのを示します。 それでも、アカウントにWindows NTパスワードハッシュがないと、LANマネージャ応答は使用されるでしょう、例えば、アカウントがLANマネージャ2.xアカウントデータベースからアップロードされて以来パスワードが変えられていないなら。 旗が0であるなら、Windows NT応答は無視されます、そして、LANマネージャ応答は使用されています。 LANマネージャ認証の使用が推奨しないので、無いっぱいにされて、これはセット(1)とLANマネージャコンパチブルチャレンジレスポンスが分野SHOULDであったならSHOULDにいつも旗を揚げさせます。
The Name field identifies the peer's user account name. The Windows NT domain name may prefix the user's account name (e.g. "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the user account "john-doe"). If a domain is not provided, the backslash should also be omitted, (e.g. "johndoe").
Name分野は同輩のユーザアカウント名を特定します。 Windows NTドメイン名はユーザのアカウント名(例えば、"BIGCO"がユーザアカウント"john-doe"を含むWindows NTドメインである「BIGCO\johndoe」)を前に置くかもしれません。 ドメインが提供していて、また、バックスラッシュが省略されるべきであるということでないなら、(例えば、"johndoe"。)です。
Zorn & Cobb Informational [Page 3] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[3ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
7. Success Packet
7. 成功パケット
The Success packet is identical in format to the standard CHAP Success packet.
Successパケットは形式が標準のCHAP Successパケットと同じです。
8. Failure Packet
8. 失敗パケット
The Failure packet is identical in format to the standard CHAP Failure packet. There is, however, formatted text stored in the Message field which, contrary to the standard CHAP rules, affects the protocol. The Message field format is:
Failureパケットは形式が標準のCHAP Failureパケットと同じです。 しかしながら、標準のCHAP規則とは逆にプロトコルに影響するMessage分野に保存されたフォーマット済みのテキストがあります。 Messageフィールド形式は以下の通りです。
"E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv"
「Eはeeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvvと等しいです」
where
どこ
The "eeeeeeeeee" is the decimal error code (need not be 10
digits) corresponding to one of those listed below, though
implementations should deal with codes not on this list
gracefully.
"eeeeeeeeee"は以下に記載されたものの1つに対応する10進エラーコード(10ケタである必要はない)です、コードがオンでなく実装が優雅にこのリストを取扱うべきですが。
646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD
646 誤り_制限された_ログオン_時間647誤り_ACCT_は649誤り_いいえ、_DIALIN_許可691誤り_の認証_故障709誤り_変化_パスワードをPASSWD_が吐き出した648誤り_に無効にしました。
The "r" is a flag set to "1" if a retry is allowed, and "0" if
not. When the authenticator sets this flag to "1" it disables
short timeouts, expecting the peer to prompt the user for new
credentials and resubmit the response.
そして、「r」がセットされた旗である、「何1インチも、再試行がaであるなら許されている、「0インチ、そうでなければ、」 固有識別文字が「何1インチも、短いタイムアウトを無効にします、同輩が新しい資格証明書のためにユーザをうながして、応答を再提出すると予想して」この旗を設定すると。
The "cccccccccccccccc" is 16 hexadecimal digits representing an
ASCII representation of a new challenge value. This field is
optional. If it is not sent, the authenticator expects the
resubmitted response to be calculated based on the previous
challenge value plus decimal 23 in the first octet, i.e. the
one immediately following the Value Size field. Windows 95
authenticators may send this field. Windows NT authenticators
do not, but may in the future. Both systems implement peer
support of this field.
"cccccccccccccccc"は新しい挑戦価値のASCII表現を表す16の16進数字です。 この分野は任意です。 それが送られないなら、固有識別文字は、前の挑戦値と10進23に基づいて再提出された応答が最初の八重奏(すなわち、すぐにValue Size野原に続くもの)で計算されると予想します。 Windows95固有識別文字はこの野原を送るかもしれません。 Windows NT固有識別文字はそうしませんが、将来、そうするかもしれません。 両方のシステムはこの分野のピアサポートを実装します。
The "vvvvvvvvvv" is the decimal version code (need not be 10
digits) indicating the MS-CHAP protocol version supported on
the server. Currently, this is interesting only in selecting a
Change Password packet type. If the field is not present the
version should be assumed to be 1; since use of the version 1
"vvvvvvvvvv"はサーバでサポートされたさん-CHAPプロトコルバージョンを示す10進バージョンコード(10ケタである必要はない)です。現在、これは単にChange Passwordパケットタイプを選ぶのにおいておもしろいです。 分野が存在していないなら、バージョンは1であると思われるべきです。 バージョン1の使用以来
Zorn & Cobb Informational [Page 4] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[4ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Change Password packet has been deprecated, this field SHOULD
always contain a value greater than or equal to 2.
変化Passwordパケットが推奨しない、この分野SHOULDはいつも値より多くの2を含んでいます。
Implementations should accept but ignore additional text they do not recognize.
実装は、彼らが認識しない追加テキストを受け入れますが、無視するべきです。
9. Change Password Packet (version 1)
9. 変化パスワードパケット(バージョン1)
The version 1 Change Password packet does not appear in standard CHAP. It allows the peer to change the password on the account specified in the previous Response packet. The version 1 Change Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one in the Message field of the Failure packet.
バージョン1Change Passwordパケットは標準のCHAPに現れません。 それで、同輩は前のResponseパケットで指定されたアカウントに関するパスワードを変えることができます。 固有識別文字レポートERROR_PASSWD_EXPIRED(E=648)とVがFailureパケットのMessage分野の1つとなくなるか、または等しい場合にだけ、バージョン1Change Passwordパケットを送るべきです。
The use of the Change Password Packet (version 1) has been deprecated; the format of the packet is described here for informational purposes, but peers SHOULD NOT transmit it.
Change Password Packet(バージョン1)の使用は推奨しないです。 パケットの形式は情報の目的のためにここで説明されますが、同輩SHOULD NOTはそれを伝えます。
The format of this packet is as follows:
このパケットの形式は以下の通りです:
1 octet : Code (=5)
1 octet : Identifier
2 octets: Length (=72)
16 octets: Encrypted LAN Manager Old password Hash
16 octets: Encrypted LAN Manager New Password Hash
16 octets: Encrypted Windows NT Old Password Hash
16 octets: Encrypted Windows NT New Password Hash
2 octets: Password Length
2 octets: Flags
1つの八重奏: (=5) 1つの八重奏をコード化してください: 識別子2八重奏: 長さ(=72)16の八重奏: 暗号化されたLANマネージャOldパスワードHash16八重奏: 暗号化されたLANマネージャNew Password Hash16八重奏: 暗号化されたWindows NT Old Password Hash16八重奏: 暗号化されたWindows NT New Password Hash2八重奏: パスワードLength2八重奏: 旗
Code
5
コード5
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The value is the Identifier of the received
Failure packet to which this packet responds plus 1.
Identifierがさばく識別子は、合っている要求と回答で1つの八重奏と援助です。 値はこのパケットが応じる容認されたFailureパケットと1のIdentifierです。
Length
72
長さ72
Encrypted LAN Manager New Password Hash
Encrypted LAN Manager Old Password Hash
These fields contain the LAN Manager password hash of the new
and old passwords encrypted with the last received challenge
value, as output by the routine LmEncryptedPasswordHash() (see
section A.8, below).
暗号化されたLANマネージャNew Password Hash Encrypted LANマネージャOld Password Hash These分野は最後の容認された挑戦値で暗号化された新しくて古いパスワードのLANマネージャパスワードハッシュを含んでいます、通常のLmEncryptedPasswordHash()によって出力されるように(以下のセクションA.8を見てください)。
Zorn & Cobb Informational [Page 5] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[5ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Encrypted Windows NT New Password Hash
Encrypted Windows NT Old Password Hash
These fields contain the Windows NT password hash of the new
and old passwords encrypted with the last received challenge
value, as output by the pseudo-code routine
NtEncryptedPasswordHash() (see section A.10, below).
暗号化されたWindows NT New Password Hash Encrypted Windows NT Old Password Hash These分野は最後の容認された挑戦値で暗号化された新しくて古いパスワードのWindows NTパスワードハッシュを含んでいます、中間コードの通常のNtEncryptedPasswordHash()によって出力されるように(以下のセクションA.10を見てください)。
Password Length
The length in octets of the LAN Manager compatible form of the
new password. If this value is greater than or equal to zero
and less than or equal to 14 it is assumed that the encrypted
LAN Manager password hash fields are valid. Otherwise, it is
assumed these fields are not valid, in which case the Windows
NT compatible passwords MUST be provided.
LANマネージャの八重奏におけるコンパチブル長さのLengthが形成する新しいパスワードに関するパスワード。 この値がゼロ以上と14以下であるなら、想定されて、暗号化されたLANマネージャパスワードが分野を論じ尽くすのは、有効です。 さもなければ、これらの分野が有効でないと思って、その場合、Windows NTコンパチブルパスワードを前提としなければなりません。
Flags
This field is two octets in length. It is a bit field of
option flags where 0 is the least significant bit of the 16-bit
quantity:
Thisがさばく旗は長さが2つの八重奏です。 少し、オプションの分野が0が16ビットの量の最下位ビットであるところで弛むということです:
Bit 0
If this bit is set (1), it indicates that the encrypted
Windows NT hashed passwords are valid and should be used.
If this bit is cleared (0), the Windows NT fields are not
used and the LAN Manager fields must be provided.
これが噛み付いたビット0Ifがセット(1)である、それは暗号化されたWindows NTハッシュ化されたパスワードが有効であり、使用されるべきであるのを示します。 このビットがきれいにされるなら、(0)、Windows NT分野は使用されていません、そして、LANマネージャ野原を供給しなければなりません。
Bits 1-15
Reserved, always clear (0).
ビット1-15Reserved、いつも(0)をクリアしてください。
10. Change Password Packet (version 2)
10. 変化パスワードパケット(バージョン2)
The version 2 Change Password packet does not appear in standard CHAP. It allows the peer to change the password on the account specified in the preceding Response packet. The version 2 Change Password packet should be sent only if the authenticator reports ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the Message field of the Failure packet.
バージョン2Change Passwordパケットは標準のCHAPに現れません。 それで、同輩は前のResponseパケットで指定されたアカウントに関するパスワードを変えることができます。 FailureパケットのMessage分野で固有識別文字がERROR_PASSWD_EXPIRED(E=648)を報告するだけであるか、そして、2以上のバージョンをバージョン2Change Passwordパケットに送るべきです。
This packet type is supported by Windows NT 3.51, 4.0 and recent versions of Windows 95. It is not supported by Windows NT 3.5 or early versions of Windows 95.
このパケットタイプはWindows NT3.51、4.0とWindows95の最近のバージョンによってサポートされます。 それはWindows NT3.5かWindows95の早めのバージョンによってサポートされません。
The format of this packet is as follows:
このパケットの形式は以下の通りです:
1 octet : Code
1 octet : Identifier
2 octets : Length
516 octets : Password Encrypted with Old NT Hash
1つの八重奏: コード1八重奏: 識別子2八重奏: 長さ516の八重奏: 古いNTハッシュで暗号化されたパスワード
Zorn & Cobb Informational [Page 6] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[6ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
16 octets : Old NT Hash Encrypted with New NT Hash
516 octets : Password Encrypted with Old LM Hash
16 octets : Old LM Hash Encrypted With New NT Hash
24 octets : LAN Manager compatible challenge response
24 octets : Windows NT compatible challenge response
2-octet : Flags
16の八重奏: New NT Hash516八重奏がある古いNT Hash Encrypted: Old LM Hash16八重奏があるパスワードEncrypted: 古いLM Hash Encrypted With New NT Hash24八重奏: LANマネージャコンパチブルチャレンジレスポンス24八重奏: チャレンジレスポンスのWindows NTコンパチブル2八重奏: 旗
Code
6
コード6
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The value is the Identifier of the received
Failure packet to which this packet responds plus 1.
Identifierがさばく識別子は、合っている要求と回答で1つの八重奏と援助です。 値はこのパケットが応じる容認されたFailureパケットと1のIdentifierです。
Length
1118
長さ1118
Password Encrypted with Old NT Hash
This field contains the PWBLOCK form of the new Windows NT
password encrypted with the old Windows NT password hash, as
output by the NewPasswordEncryptedWithOldNtPasswordHash()
routine (see section A.11, below).
Old NT Hash ThisとEncryptedがさばくパスワードは古いWindows NTパスワードハッシュで暗号化された新しいWindows NTパスワードのPWBLOCKフォームを含んでいます、NewPasswordEncryptedWithOldNtPasswordHash()ルーチンで出力されるように(以下のセクションA.11を見てください)。
Old NT Hash Encrypted with New NT Hash
This field contains the old Windows NT password hash encrypted
with the new Windows NT password hash, as output by the
OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see
section A.14, below).
New NT Hash This分野がある古いNT Hash Encryptedは新しいWindows NTパスワードハッシュで暗号化された古いWindows NTパスワードハッシュを含んでいます、OldNtPasswordHashEncryptedWithNewNtPasswordHash()ルーチンで出力されるように(以下のセクションA.14を見てください)。
Password Encrypted with Old LM Hash
This field contains the PWBLOCK form of the new Windows NT
password encrypted with the old LAN Manager password hash, as
output by the NewPasswordEncryptedWithOldLmPasswordHash()
routine described in section A.15, below. Note, however, that
the use of this field has been deprecated: peers SHOULD NOT
generate it, and this field SHOULD be zero-filled.
Old LM Hash ThisとEncryptedがさばくパスワードは古いLANマネージャパスワードハッシュで暗号化された新しいWindows NTパスワードのPWBLOCKフォームを含んでいます、以下のセクションA.15で説明されたNewPasswordEncryptedWithOldLmPasswordHash()ルーチンで出力されるように。 しかしながら、この分野の使用が推奨しないことに注意してください: 無いっぱいにされて、SHOULD NOTがそれ、およびこれを生成する同輩はSHOULDをさばきます。
Old LM Hash Encrypted With New NT Hash
This field contains the old LAN Manager password hash encrypted
with the new Windows NT password hash, as output by the
OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see
section A.16, below). Note, however, that the use of this
field has been deprecated: peers SHOULD NOT generate it, and
this field SHOULD be zero-filled.
古いLM Hash Encrypted With New NT Hash This分野は新しいWindows NTパスワードハッシュで暗号化された古いLANマネージャパスワードハッシュを含んでいます、OldLmPasswordHashEncryptedWithNewNtPasswordHash()ルーチンで出力されるように(以下のセクションA.16を見てください)。 しかしながら、この分野の使用が推奨しないことに注意してください: 無いっぱいにされて、SHOULD NOTがそれ、およびこれを生成する同輩はSHOULDをさばきます。
Zorn & Cobb Informational [Page 7] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[7ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
LAN Manager compatible challenge response
Windows NT compatible challenge response
The challenge response field (as described in the Response
packet description), but calculated on the new password and the
same challenge used in the last response. Note that use of the
LAN Manager compatible challenge response has been deprecated;
peers SHOULD NOT generate it, and the field SHOULD be zero-
filled.
チャレンジレスポンス分野(Responseパケット記述で説明されるように)の、しかし、新しいパスワードで計算されたLANマネージャコンパチブルチャレンジレスポンスWindows NTコンパチブルチャレンジレスポンスと同じくらいは最後の応答で使用されていた状態で挑戦します。 LANマネージャコンパチブルチャレンジレスポンスの使用が推奨しないことに注意してください。 無いっぱいにされて、SHOULD NOTがそれ、および分野SHOULDを生成する同輩。
Flags
This field is two octets in length. It is a bit field of
option flags where 0 is the least significant bit of the 16-bit
quantity. The format of this field is illustrated in the
following diagram:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 0
The "use Windows NT compatible challenge response" flag
as described in the Response packet.
噛み付かれました。0 Responseパケットの「Windows NTコンパチブルチャレンジレスポンスを使用してください」という説明されるとしての旗。
Bit 1
Set (1) indicates that the "Password Encrypted with Old
LM Hash" and "Old LM Hash Encrypted With New NT Hash"
fields are valid and should be used. Clear (0) indicates
these fields are not valid. This bit SHOULD always be
clear (0).
ビット1Set(1)は、「古いLMハッシュで暗号化されたパスワード」と「新しいNTハッシュで暗号化された古いLMハッシュ」分野が有効であり、使用されるべきであるのを示します。 明確な(0)は、これらの分野が有効でないことを示します。 これはいつもSHOULDに噛み付きました。明確な(0)になってください。
Bits 2-15
Reserved, always clear (0).
ビット2-15Reserved、いつも(0)をクリアしてください。
11. Security Considerations
11. セキュリティ問題
As an implementation detail, the authenticator SHOULD limit the number of password retries allowed to make brute-force password guessing attacks more difficult.
実装の詳細として、固有識別文字SHOULDはブルートフォースパスワード推測攻撃をより難しくすることができたパスワード再試行の数を制限します。
Because the challenge value is encrypted using the password hash to form the response and the challenge is transmitted in clear-text form, both passive known-plaintext and active chosen-plaintext attacks against the password hash are possible. Suitable precautions (i.e., frequent password changes) SHOULD be taken in environments where eavesdropping is likely.
挑戦値が応答を形成するのにパスワードハッシュを使用することで暗号化されていて、挑戦がクリアテキストフォームで伝えられるので、パスワードハッシュに対する両方の受け身の知られている平文の、そして、活発な選ばれた平文攻撃は可能です。 適当な注意、(すなわち、盗聴がそうである中に入れている環境がありそうであったなら、パスワード変化) SHOULDによく行ってください。
Zorn & Cobb Informational [Page 8] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[8ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
The Change Password (version 1) packet is vulnerable to a passive eavesdropping attack which can easily reveal the new password hash. For this reason, it MUST NOT be sent if eavesdropping is possible.
Change Password(バージョン1)パケットは容易に新しいパスワードハッシュを明らかにすることができる受け身の盗聴攻撃に被害を受け易いです。 この理由で、盗聴が可能であるなら、それを送ってはいけません。
12. References
12. 参照
[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:
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065-1031
[6] RC4は情報、接触を認可するRSA Data Security株式会社Forからライセンスの下で利用可能な独占暗号化アルゴリズムです: 海洋のParkwayレッドウッドシティー、RSA Data Security Inc.100カリフォルニア94065-1031
[7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recomnendations for Security", RFC 1750, December 1994.
1994年12月の[7] イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性Recomnendations」RFC1750。
[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] "DES Modes of Operation", Federal Information Processing
Standards Publication 81, National Institute of Standards and
Technology, December 1980
[9] 「DES運転モード」、公表81、1980年12月の連邦政府の情報処理規格米国商務省標準技術局
13. Acknowledgements
13. 承認
Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), Bill Palter (palter@network-alchemy.com), Bruce Johnson (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) for useful suggestions and feedback.
役に立つ提案とフィードバックをジェフ・ハーグ( Jeff_Haag@3com.com )、ビルPalter( palter@network-alchemy.com )、ブルース・ジョンソン( bjohnson@microsoft.com )、トニー・ベル( tonybe@microsoft.com )、ブノワ・マーチン( ehlija@vircom.com )、およびジョー・デイヴィース( josephd@microsoft.com )をありがとうございます(特に決まった順番でなく)。
Zorn & Cobb Informational [Page 9] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[9ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
14. Chair's Address
14. 議長のアドレス
The PPP Extensions Working Group can be contacted via the current chair:
現在のいすを通してPPP Extensions作業部会に連絡できます:
Karl Fox Ascend Communications 3518 Riverside Drive Suite 101 Columbus, OH 43221
カールフォックスはコミュニケーション3518川沿いのドライブウェイSuite101コロンブス、OH 43221を昇ります。
Phone: +1 614 326 6841 EMail: karl@ascend.com
以下に電話をしてください。 +1 6841年の614 326メール: karl@ascend.com
15. Authors' Addresses
15. 作者のアドレス
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: glennz@microsoft.com
以下に電話をしてください。 +1 425 703、1559Fax: +1 7329年の425 936メール: glennz@microsoft.com
Steve Cobb Microsoft Corporation One Microsoft Way Redmond, Washington 98052
Steve Cobbマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: stevec@microsoft.com
メール: stevec@microsoft.com
Zorn & Cobb Informational [Page 10] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[10ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Appendix A - Pseudocode
付録A--擬似コード
The routines mentioned in the text are described in pseudocode below.
テキストで言及されたルーチンは以下の擬似コードで説明されます。
A.1 LmChallengeResponse()
A.1 LmChallengeResponse()
LmChallengeResponse(
IN 8-octet Challenge,
IN 0-to-14-oem-char Password,
OUT 24-octet Response )
{
LmPasswordHash( Password, giving PasswordHash )
ChallengeResponse( Challenge, PasswordHash, giving Response )
}
LmChallengeResponse(8八重奏の挑戦、14-oem炭への0パスワードの出ている24八重奏の応答)LmPasswordHash(PasswordHashに与えるパスワード)ChallengeResponse(挑戦、Responseに与えるPasswordHash)
A.2 LmPasswordHash()
A.2 LmPasswordHash()
LmPasswordHash(
IN 0-to-14-oem-char Password,
OUT 16-octet PasswordHash )
{
Set UcasePassword to the uppercased Password
Zero pad UcasePassword to 14 characters
LmPasswordHash(IN14-oem炭への0Password、OUTの16八重奏のPasswordHash)、14のキャラクタへの大文字されたPassword ZeroパッドUcasePasswordにUcasePasswordを設定してください。
DesHash( 1st 7-octets of UcasePassword,
giving 1st 8-octets of PasswordHash )
DesHash(PasswordHashの最初の8八重奏を与えるUcasePasswordの最初の7八重奏
DesHash( 2nd 7-octets of UcasePassword,
giving 2nd 8-octets of PasswordHash )
}
DesHash(PasswordHashの2番目の8八重奏を与えるUcasePasswordの2番目の7八重奏)
A.3 DesHash()
A.3 DesHash()
DesHash(
IN 7-octet Clear,
OUT 8-octet Cypher )
{
/*
* Make Cypher an irreversibly encrypted form of Clear by
* encrypting known text using Clear as the secret key.
* The known text consists of the string
*
* KGS!@#$%
*/
/**は秘密鍵としてClearを使用することで知られているテキストを暗号化して、*でCypherをClearの逆転できないように暗号化されたフォームにします。DesHash(INの7八重奏のClear、OUTの8八重奏のCypher)、*知られているテキストはストリング**KGS!@#$% */から成ります。
Set StdText to "KGS!@#$%"
「KGS!@#$%」にStdTextを設定してください。
Zorn & Cobb Informational [Page 11] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[11ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
DesEncrypt( StdText, Clear, giving Cypher )
}
DesEncrypt(StdText、Cypherに与えるClear)
A.4 DesEncrypt()
A.4 DesEncrypt()
DesEncrypt(
IN 8-octet Clear,
IN 7-octet Key,
OUT 8-octet Cypher )
{
/*
* Use the DES encryption algorithm [4] in ECB mode [9]
* to encrypt Clear into Cypher such that Cypher can
* only be decrypted back to Clear by providing Key.
* Note that the DES algorithm takes as input a 64-bit
* stream where the 8th, 16th, 24th, etc. bits are
* parity bits ignored by the encrypting algorithm.
* Unless you write your own DES to accept 56-bit input
* without parity, you will need to insert the parity bits
* yourself.
*/
}
DesEncrypt(8八重奏では、7八重奏の主要で、出ている8八重奏の暗号化でクリアしてください){ Cypherが使用できるだけであって、/**は、提供するのによるClearへの解読された後部がKeyであったならClearをCypherに暗号化するのにECBモード[9]*にDES暗号化アルゴリズム[4]を使用します。 * DESアルゴリズムが入力として8番目、16番目と、24番目に、などビットが無視された*パリティビットであるところのそばで64ビットの*ストリームをみなすことに注意してください。暗号化アルゴリズム。 * 同等なしで56ビットの入力*を受け入れるためにあなた自身のDESに書かないと、あなたは、自分でパリティビット*を挿入する必要があるでしょう。 */ }
A.5 NtChallengeResponse()
A.5 NtChallengeResponse()
NtChallengeResponse(
IN 8-octet Challenge,
IN 0-to-256-unicode-char Password,
OUT 24-octet Response )
{
NtPasswordHash( Password, giving PasswordHash )
ChallengeResponse( Challenge, PasswordHash, giving Response )
}
NtChallengeResponse(8八重奏の挑戦、0が256ユニコードに焦げているパスワードの出ている24八重奏の応答)NtPasswordHash(PasswordHashに与えるパスワード)ChallengeResponse(挑戦、Responseに与えるPasswordHash)
A.6 NtPasswordHash()
A.6 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.
*/
/**は、Password*をPasswordHashに逆転できないように論じ尽くすのにMD4アルゴリズム[5]を使用します。NtPasswordHash(0が256ユニコードに焦げているIN Password、OUTの16八重奏のPasswordHash)、どんな終わり0*/も含んでいて、パスワードだけが*なしで論じ尽くされます。
Zorn & Cobb Informational [Page 12] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[12ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
}
}
A.7 ChallengeResponse()
A.7 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八重奏)
A.8 LmEncryptedPasswordHash()
A.8 LmEncryptedPasswordHash()
LmEncryptedPasswordHash(
IN 0-to-14-oem-char Password,
IN 8-octet KeyValue,
OUT 16-octet Cypher )
{
LmPasswordHash( Password, giving PasswordHash )
LmEncryptedPasswordHash(14-oem炭への0パスワード、8八重奏のKeyValueでの出ている16八重奏の暗号化)、LmPasswordHash(PasswordHashに与えるパスワード
PasswordHashEncryptedWithBlock( PasswordHash,
KeyValue,
giving Cypher )
}
PasswordHashEncryptedWithBlock(PasswordHash、Cypherに与えるKeyValue)
A.9 PasswordHashEncryptedWithBlock()
A.9 PasswordHashEncryptedWithBlock()
PasswordHashEncryptedWithBlock(
IN 16-octet PasswordHash,
IN 8-octet Block,
OUT 16-octet Cypher )
{
PasswordHashEncryptedWithBlock(16八重奏のPasswordHash、8八重奏のブロックでの出ている16八重奏の暗号化)
Zorn & Cobb Informational [Page 13] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[13ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
DesEncrypt( 1st 8-octets PasswordHash,
1st 7-octets Block,
giving 1st 8-octets Cypher )
DesEncrypt(最初の8八重奏のPasswordHash、最初の8八重奏のCypherに与える最初の7八重奏のBlock)
DesEncrypt( 2nd 8-octets PasswordHash,
1st 7-octets Block,
giving 2nd 8-octets Cypher )
}
DesEncrypt(第2 8八重奏のPasswordHash、第2 8八重奏のCypherに与える最初の7八重奏のBlock)
A.10 NtEncryptedPasswordHash()
A.10 NtEncryptedPasswordHash()
NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet
Challenge OUT 16-octet Cypher ) {
NtPasswordHash( Password, giving PasswordHash )
NtEncryptedPasswordHash(14-oem炭への0のINの8八重奏の挑戦出ている16八重奏のパスワード暗号化における)、NtPasswordHash(PasswordHashに与えるパスワード
PasswordHashEncryptedWithBlock( PasswordHash,
Challenge,
giving Cypher )
}
PasswordHashEncryptedWithBlock(PasswordHash、Cypherに与えるChallenge)
A.11 NewPasswordEncryptedWithOldNtPasswordHash()
A.11 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)
A.12 EncryptPwBlockWithPasswordHash()
A.12 EncryptPwBlockWithPasswordHash()
EncryptPwBlockWithPasswordHash( IN 0-to-256-unicode-char Password, IN 16-octet PasswordHash,
EncryptPwBlockWithPasswordHash、(0が256ユニコードに焦げているパスワード、16八重奏のPasswordHashで
Zorn & Cobb Informational [Page 14] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[14ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
OUT datatype-PWBLOCK PwBlock )
{
出ているデータ型式-PWBLOCK PwBlock) {
Fill ClearPwBlock with random octet values
PwSize = lstrlenW( Password ) * sizeof( unicode-char )
PwOffset = sizeof( ClearPwBlock.Password ) - PwSize
Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password
ClearPwBlock.PasswordLength = PwSize
Rc4Encrypt( ClearPwBlock,
sizeof( ClearPwBlock ),
PasswordHash,
sizeof( PasswordHash ),
giving PwBlock )
}
無作為の八重奏がある中詰めClearPwBlockは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に与えて)。
A.13 Rc4Encrypt()
A.13 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]を使用します。 */ }
A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash()
A.14 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)
Zorn & Cobb Informational [Page 15] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[15ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
A.15 NewPasswordEncryptedWithOldLmPasswordHash()
A.15 NewPasswordEncryptedWithOldLmPasswordHash()
NewPasswordEncryptedWithOldLmPasswordHash(
IN 0-to-256-unicode-char NewPassword,
IN 0-to-256-unicode-char OldPassword,
OUT datatype-PWBLOCK EncryptedPwBlock )
{
LmPasswordHash( OldPassword, giving PasswordHash )
NewPasswordEncryptedWithOldLmPasswordHash(0が256ユニコードに焦げているNewPassword、0が256ユニコードに焦げているOldPasswordの出ているデータ型式-PWBLOCK EncryptedPwBlock)、LmPasswordHash(PasswordHashに与えるOldPassword
EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash,
giving EncryptedPwBlock )
}
EncryptPwBlockWithPasswordHash(NewPassword、EncryptedPwBlockに与えるPasswordHash)
A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash()
OldLmPasswordHashEncryptedWithNewNtPasswordHash(
IN 0-to-256-unicode-char NewPassword,
IN 0-to-256-unicode-char OldPassword,
OUT 16-octet EncryptedPasswordHash )
{
LmPasswordHash( OldPassword, giving OldPasswordHash )
OldLmPasswordHashEncryptedWithNewNtPasswordHash(0が256ユニコードに焦げているNewPassword、0が256ユニコードに焦げているOldPasswordの出ている16八重奏のEncryptedPasswordHash)、LmPasswordHash(OldPasswordHashに与えるOldPassword
NtPasswordHash( NewPassword, giving NewPasswordHash )
NtPasswordHash(NewPasswordHashに与えるNewPassword
NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash,
giving EncrytptedPasswordHash )
}
NtPasswordHashEncryptedWithBlock(OldPasswordHash、EncrytptedPasswordHashに与えるNewPasswordHash)
A.17 NtPasswordHashEncryptedWithBlock()
A.17 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)
Zorn & Cobb Informational [Page 16] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[16ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Appendix B - Examples
付録B--例
B.1 Negotiation Examples
B.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は各認証再試行Responseと変化パスワード応答のときに増加されます。 パケット系列IDがアップデートされるすべてのケースが以下に述べられます。
Response retry is never allowed after Change Password. Change Password may occur after Response retry. The implied challenge form is shown in the examples, though all cases of "first challenge+23" should be replaced by the "C=cccccccccccccccc" challenge if authenticator supplies it in the Failure packet.
応答再試行はChange Passwordの後に決して許されていません。 Responseが再試行した後に変化Passwordは起こるかもしれません。 暗示している挑戦書式は例に示されます、固有識別文字がFailureパケットでそれを供給するなら、「最初に、挑戦+23」に関するすべてのケースを「C=cccccccccccccccc」挑戦に取り替えるべきですが。
B.1.1 Successful authentication
B.1.1のうまくいっている認証
<- Challenge
Response ->
<- Success
<チャレンジレスポンス-><成功
B.1.2 Failed authentication with no retry allowed
再試行が全く許されていない状態で、B.1.2は認証に失敗しました。
<- Challenge
Response ->
<- Failure (E=691 R=0)
<チャレンジレスポンス-><失敗(691E=R=0)
B.1.3 Successful authentication after retry
再試行の後のB.1.3のうまくいっている認証
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Success
<Response-><失敗(Eは691R=1と等しい)に挑戦してください、そして、短いタイムアウトResponse(+ + ID)を最初の挑戦+23-><成功に無効にしてください。
B.1.4 Failed hack attack with 3 attempts allowed
3つの試みが許されている状態で、B.1.4はハッキング攻撃に失敗しました。
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23+23 ->
<Response-><失敗(Eは691R=1と等しい)に挑戦してください、そして、最初の挑戦+23-><の故障(Eは691R=1と等しい)に短いタイムアウトResponse(+ + ID)を無効にしてください、そして、短いタイムアウトResponse(+ + ID)を無効にして、最初に、+23+23->に挑戦してください。
Zorn & Cobb Informational [Page 17] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[17ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
<- Failure (E=691 R=0)
<の故障(691E=R=0)
B.1.5 Successful authentication with password change
パスワード変化に伴うB.1.5のうまくいっている認証
<- Challenge
Response ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge ->
<- Success
<Response-><失敗(Eは648R=0 V=2と等しい)に挑戦してください、そして、短いタイムアウトChangePassword(+ + ID)を最初の挑戦-><成功に無効にしてください。
B.1.6 Successful authentication with retry and password change
再試行とパスワード変化に伴うB.1.6のうまくいっている認証
<- Challenge
Response ->
<- Failure (E=691 R=1), disable short timeout
Response (++ID) to first challenge+23 ->
<- Failure (E=648 R=0 V=2), disable short timeout
ChangePassword (++ID) to first challenge+23 ->
<- Success
<Response-><失敗(Eは691R=1と等しい)に挑戦してください、そして、最初の挑戦+23-><の故障(Eは648R=0 V=2と等しい)に短いタイムアウトResponse(+ + ID)を無効にしてください、そして、短いタイムアウトChangePassword(+ + ID)を最初の挑戦+23-><成功に無効にしてください。
B.2 Hash Example
B.2細切れ肉料理の例
Intermediate values for password "MyPw".
中間的はパスワードのために"MyPw"を評価します。
8-octet Challenge: 10 2D B5 DF 08 5D 30 41
8八重奏の挑戦: 10 2D B5 DF08 5D30 41
0-to-256-unicode-char NtPassword: 4D 00 79 00 50 00 77 00
0が256ユニコードに焦げているNtPassword: 4D00 79 00 50 00 77 00
16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16八重奏のNtPasswordHash: 4FC15 6A F7エドCD6C0E DD E3 33 7D42 7F Eの西暦
24-octet NtChallengeResponse: 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C A4 C3 51 AB 40 9A 3D 61
24八重奏のNtChallengeResponse: 4 9D3C8F9EのC FD38 5D 5B F4 D3 24 67 91 95 6C A4 C3 51AB40 9A3D61
B.3 Example of DES Key Generation
DESキー生成に関するB.3の例
DES uses 56-bit keys, expanded to 64 bits by the insertion of parity bits. After the parity of the key has been fixed, every eighth bit is a parity bit and the number of bits that are set (1) in each octet is odd; i.e., odd parity. Note that many DES engines do not check parity, however, simply stripping the parity bits. The following example illustrates the values resulting from the use of the 16-octet NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys
DESはパリティビットの挿入で64ビットに広げられた56ビットのキーを使用します。 キーの同等が修理された後に、8番目のビット毎はパリティビットです、そして、各八重奏でセット(1)であるビットの数は変です。 すなわち、奇数パリティ。 しかしながら、多くのDESエンジンが単にパリティビットを剥取りながら同等をチェックしないことに注意してください。 以下の例は1組のDESキーを発生させるようにAppendix B.2で見せられた16八重奏のNTPasswordHashの使用から生じる値を例証します。
Zorn & Cobb Informational [Page 18] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[18ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in Appendix A.17).
(例えば、Appendix A.17で説明されたNtPasswordHashEncryptedWithBlock()における使用のための。)
16-octet NtPasswordHash: FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC
16八重奏のNtPasswordHash: 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
Zorn & Cobb Informational [Page 19] RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998
ゾルンとコッブ情報[19ページ]のRFC2433マイクロソフトpppやつ拡張子Ocotober1998
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Zorn & Cobb Informational [Page 20]
ゾルンとコッブInformationalです。[20ページ]
一覧
スポンサーリンク
