RFC2548 日本語訳
2548 Microsoft Vendor-specific RADIUS Attributes. G. Zorn. March 1999. (Format: TXT=80763 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Zorn Request for Comments: 2548 Microsoft Corporation Category: Informational March 1999
コメントを求めるワーキンググループG.ゾルン要求をネットワークでつないでください: 2548年のマイクロソフト社カテゴリ: 情報の1999年3月
Microsoft Vendor-specific RADIUS Attributes
マイクロソフトのベンダー特有の半径属性
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.
このドキュメントはマイクロソフトのベンダー特有のRADIUS属性のセットについて説明します。 これらの属性は、マイクロソフトの独占ダイヤルアップがプロトコルであるとサポートする、そして/または、標準のRADIUS属性セット[3]によって提供されない特徴のサポートを提供するように設計されています。 マイクロソフトが新しいベンダー特有の属性を定義するときはいつも、このメモをアップデートすると予想されます、プライマリ目的がマイクロソフト製品で共同利用したがっている第三者の開いていて、容易にアクセス可能な参照を提供することであるので。
1. Specification of Requirements
1. 要件の仕様
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]で説明されるように解釈されることになっていてください、」であるべきです
2. Attributes
2. 属性
The following sections describe sub-attributes which may be transmitted in one or more RADIUS attributes of type Vendor-Specific [3]. More than one sub-attribute MAY be transmitted in a single Vendor-Specific Attribute; if this is done, the sub-attributes SHOULD be packed as a sequence of Vendor-Type/Vendor-Length/Value triples following the inital Type, Length and Vendor-ID fields. The Length field of the Vendor-Specific Attribute MUST be set equal to the sum of the Vendor-Length fields of the sub-attributes contained in the Vendor-Specific Attribute, plus six. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be set to decimal 311 (Microsoft).
以下のセクションはタイプの1つ以上のRADIUS属性で伝えられるかもしれないサブ属性のVendor特有の[3]について説明します。 1つ以上のサブ属性が独身のVendor特有のAttributeで伝えられるかもしれません。 これは完了しています、サブ属性SHOULD。inital Typeに続いて、ベンダーVendor-タイプ/長さ/価値の系列が3倍になるのに従って、梱包されてください、LengthとVendor-ID分野。 Vendor特有のAttributeのLength分野はVendor特有のAttribute、および6に含まれたサブ属性のVendor-長さの分野の合計と等しいセットであるに違いありません。 Vendor特有のAttribute(s)のVendor-ID分野を10進311(マイクロソフト)に設定しなければなりません。
Zorn Informational [Page 1] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[1ページ]のRFC2548マイクロソフト
2.1. Attributes for Support of MS-CHAP Version 1
2.1. やつVersionさん1のサポートのための属性
2.1.1. Introduction
2.1.1. 序論
Microsoft created Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [4] to authenticate remote Windows workstations, providing the functionality to which LAN-based users are accustomed. Where possible, MS-CHAP is consistent with standard CHAP [5], and the differences are easily modularized. Briefly, the differences between MS-CHAP and standard CHAP are:
マイクロソフトはリモートWindowsワークステーションを認証するためにマイクロソフトチャレンジ・ハンドシェイク認証プロトコル(さん-CHAP)[4]を作成しました、LANベースのユーザが慣れている機能性を提供して。 可能であるところでは、さん-CHAPが標準のCHAP[5]と一致しています、そして、違いが容易にmodularizedされます。 簡潔に、さん-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 Windows NT 3.5, 3.51 and 4.0,
Microsoft Windows95, and Microsoft LAN Manager 2.x 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、およびマイクロソフトLANマネージャ2.xネットワーク製品との互換性のために設計された形式にはさん-CHAP Responseパケットがあります。 さん-CHAP形式は、クリアテキストかreversibly暗号化されたパスワードを保存するために固有識別文字を必要としません。
* MS-CHAP provides an authenticator-controlled authentication
retry mechanism.
* さん-CHAPは固有識別文字で制御された認証再試行メカニズムを提供します。
* MS-CHAP provides an authenticator-controlled password changing
mechanism.
* さん-CHAPは固有識別文字で制御されたパスワード変化メカニズムを提供します。
* MS-CHAP defines an extended set of reason-for-failure codes,
returned in the Failure packet Message field.
* さん-CHAPはFailureパケットMessage分野で返された拡張セットの失敗の理由コードを定義します。
The attributes defined in this section reflect these differences.
このセクションで定義された属性はこれらの違いを反映します。
2.1.2. MS-CHAP-Challenge
2.1.2. やつChallengeさん
Description
記述
This Attribute contains the challenge sent by a NAS to a Microsoft
Challenge-Handshake Authentication Protocol (MS-CHAP) user. It
MAY be used in both Access-Request and Access-Challenge packets.
このAttributeはマイクロソフトチャレンジ・ハンドシェイク認証プロトコル(さん-CHAP)ユーザにNASによって送られた挑戦を含んでいます。 それは両方のAccess-要求とAccess-挑戦パケットで使用されるかもしれません。
A summary of the MS-CHAP-Challenge Attribute format is shown below. The fields are transmitted from left to right.
CHAP Challenge Attribute形式さんの概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn Informational [Page 2] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[2ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
11 for MS-CHAP-Challenge.
やつChallengeさんのための11をベンダーでタイプしてください。
Vendor-Length
> 2
ベンダー長さの>2
String
The String field contains the MS-CHAP challenge.
Stringがさばくストリングはさん-CHAP挑戦を含んでいます。
2.1.3. MS-CHAP-Response
2.1.3. やつResponseさん
Description
記述
This Attribute contains the response value provided by a PPP
Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)
user in response to the challenge. It is only used in Access-
Request packets.
このAttributeは挑戦に対応してPPPマイクロソフトチャレンジ・ハンドシェイク認証プロトコル(さん-CHAP)ユーザによって提供された応答値を含んでいます。 それはAccessリクエスト・パケットで使用されるだけです。
A summary of the MS-CHAP-Response Attribute format is shown below. The fields are transmitted from left to right.
CHAP Response Attribute形式さんの概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn Informational [Page 3] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[3ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Ident | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Ident| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LM-Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response(cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NT-Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
1 for MS-CHAP-Response.
やつResponseさんのための1をベンダーでタイプしてください。
Vendor-Length
52
ベンダー長さの52
Ident
Identical to the PPP CHAP Identifier.
pppと同じIdentは識別子のひびが切れます。
Flags
The Flags field is one octet in length. If the Flags field is one
(0x01), the NT-Response field is to be used in preference to the
LM-Response field for authentication. The LM-Response field MAY
still be used (if non-empty), but the NT-Response SHOULD be tried
first. If it is zero, the NT-Response field MUST be ignored and
the LM-Response field used.
Flagsがさばく旗は長さが1つの八重奏です。 Flags分野が1つ(0×01)であるなら、NT-応答分野は認証のためのLM-応答分野に優先して使用されることです。 LM-応答分野は、まだ中古、そして、(非空)であるかもしれなく、唯一のNT-応答はSHOULDです。最初に、試みられます。 それがゼロであるなら、NT-応答分野は、無視されていて使用されるLM-応答分野であるに違いありません。
Zorn Informational [Page 4] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[4ページ]のRFC2548マイクロソフト
LM-Response
The LM-Response field is 24 octets in length and holds an encoded
function of the password and the received challenge. If this
field is empty, it SHOULD be zero-filled.
LM-応答がさばくLM-応答は、長さにおける24の八重奏であり、パスワードのコード化された機能と容認された挑戦を保持します。 分野はこれであるなら人影がなく、それはSHOULDです。無いっぱいにされてください。
NT-Response
NT-応答
The NT-Response field is 24 octets in length and holds an encoded
function of the password and the received challenge. If this
field is empty, it SHOULD be zero-filled.
NT-応答分野は、長さにおける24の八重奏であり、パスワードのコード化された機能と容認された挑戦を保持します。 分野はこれであるなら人影がなく、それはSHOULDです。無いっぱいにされてください。
2.1.4. MS-CHAP-Domain
2.1.4. やつDomainさん
Description
記述
The MS-CHAP-Domain Attribute indicates the Windows NT domain in
which the user was authenticated. It MAY be included in both
Access-Accept and Accounting-Request packets.
CHAP Domain Attributeさんはユーザが認証されたWindows NTドメインを示します。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
A summary of the MS-CHAP-Domain Attribute format is given below. The fields are transmitted left to right.
CHAP Domain Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Ident | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Ident| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
10 for MS-CHAP-Domain.
やつDomainさんへの10をベンダーでタイプしてください。
Vendor-Length
> 3
ベンダー長さの>3
Ident
The Ident field is one octet and aids in matching requests and
replies.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。
String
This field contains the name in ASCII of the Windows NT domain in
which the user was authenticated.
ストリングThis分野はユーザが認証されたWindows NTドメインのASCIIにおける名前を含んでいます。
Zorn Informational [Page 5] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[5ページ]のRFC2548マイクロソフト
2.1.5. MS-CHAP-Error
2.1.5. やつErrorさん
Description
記述
The MS-CHAP-Error Attribute contains error data related to the
preceding MS-CHAP exchange. This Attribute may be used in both
MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used
in Access-Reject packets.
CHAP Error Attributeさんは前のさん-CHAP交換に関連するエラー・データを含みます。 このAttributeはさん-CHAP-V1とさん-CHAP-V2(以下を見る)交換の両方で使用されるかもしれません。 それはAccess-廃棄物パケットで使用されるだけです。
A summary of the MS-CHAP-Error Attribute format is given below. The fields are transmitted left to right.
CHAP Error Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Ident | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Ident| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
2 for MS-CHAP-Error.
やつErrorさんのための2をベンダーでタイプしてください。
Vendor-Length
> 3
ベンダー長さの>3
Ident
The Ident field is one octet and aids in matching requests and
replies.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。
String
This field contains specially formatted ASCII text, which is
interpreted by the authenticating peer.
ストリングThis分野は特に、フォーマットされたASCIIテキストを含んでいます。(それは、認証している同輩によって解釈されます)。
2.1.6. MS-CHAP-CPW-1
2.1.6. やつCPW-1さん
Description
記述
This Attribute allows the user to change their password if it has
expired. This Attribute is only used in Access-Request packets, and
should only be included if an MS-CHAP-Error attribute was included in
the immediately preceding Access-Reject packet, the String field of
the MS-CHAP-Error attribute indicated that the user password had
expired, and the MS-CHAP version is less than 2.
期限が切れたなら、このAttributeはユーザにそれらのパスワードを変えさせます。 このAttributeはAccess-リクエスト・パケットで使用されるだけであり、CHAPさんというError属性人がすぐに前のAccess-廃棄物パケットに含まれている場合にだけ、含まれているでしょうに、そして、CHAP Error属性さんのString分野は、ユーザパスワードが期限が切れたのを示しました、そして、さん-CHAPバージョンは2未満です。
A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The fields are transmitted from left to right.
さん-CHAP-CPW-1 Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn Informational [Page 6] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[6ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Code | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-Old-Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Old-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Old-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Old-Password (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-New-Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-New-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-New-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-New-Password (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-Old-Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Old-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Old-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Old-Password (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-New-Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-New-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-New-Password (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-New-Password (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New-LM-Password-Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| コード| Ident| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 古い..パスワード..古い..パスワード..古い..パスワード..古い..パスワード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しい..パスワード..新しい..パスワード..新しい..パスワード..新しい..パスワード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 古い..パスワード..古い..パスワード..古い..パスワード..古い..パスワード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しい..パスワード..新しい..パスワード..新しい..パスワード..新しい..パスワード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しいLMパスワードの長さ| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
3 for MS-CHAP-PW-1
やつPW-1さんのためのベンダータイプ3
Vendor-Length
72
ベンダー長さの72
Code
The Code field is one octet in length. Its value is always 5.
Codeがさばくコードは長さが1つの八重奏です。 いつも値は5です。
Zorn Informational [Page 7] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[7ページ]のRFC2548マイクロソフト
Ident
The Ident field is one octet and aids in matching requests and
replies.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。
LM-Old-Password
The LM-Old-Password field is 16 octets in length. It contains the
encrypted Lan Manager hash of the old password.
LMの古いパスワード、LMの古いパスワード欄は長さが16の八重奏です。 それは古いパスワードの暗号化されたランマネージャハッシュを含んでいます。
LM-New-Password
The LM-New-Password field is 16 octets in length. It contains the
encrypted Lan Manager hash of the new password.
LMの新しいパスワード、LMの新しいパスワード欄は長さが16の八重奏です。 それは新しいパスワードの暗号化されたランマネージャハッシュを含んでいます。
NT-Old-Password
The NT-Old-Password field is 16 octets in length. It contains the
encrypted Lan Manager hash of the old password.
NTの古いパスワード、NTの古いパスワード欄は長さが16の八重奏です。 それは古いパスワードの暗号化されたランマネージャハッシュを含んでいます。
NT-New-Password
The NT-New-Password field is 16 octets in length. It contains the
encrypted Lan Manager hash of the new password.
NTの新しいパスワード、NTの新しいパスワード欄は長さが16の八重奏です。 それは新しいパスワードの暗号化されたランマネージャハッシュを含んでいます。
New-LM-Password-Length
The New-LM-Password-Length field is two octets in length and
contains the length in octets of the new LAN Manager-compatible
password.
新しいLANマネージャコンパチブルパスワードのNew-LMパスワードの長さの分野が長さにおける2つの八重奏であり、長さを含む新しいLMパスワードの長さの八重奏。
Flags
The Flags field is two octets in length. If the least significant
bit of the Flags field is one, this indicates that the NT-New-
Password and NT-Old-Password fields are valid and SHOULD be used.
Otherwise, the LM-New-Password and LM-Old-Password fields MUST be
used.
Flagsがさばく旗は長さが2つの八重奏です。 これが、Flags分野の最下位ビットが1であるなら、NT新しいパスワードとNTの古いパスワード欄が有効であることを示す、SHOULD、使用されてください。 さもなければ、LMの新しいパスワードとLMの古いパスワード欄を使用しなければなりません。
2.1.7. MS-CHAP-CPW-2
2.1.7. やつCPW-2さん
Description
記述
This Attribute allows the user to change their password if it has
expired. This Attribute is only used in Access-Request packets,
and should only be included if an MS-CHAP-Error attribute was
included in the immediately preceding Access-Reject packet, the
String field of the MS-CHAP-Error attribute indicated that the
user password had expired, and the MS-CHAP version is equal to 2.
期限が切れたなら、このAttributeはユーザにそれらのパスワードを変えさせます。 このAttributeはAccess-リクエスト・パケットで使用されるだけであり、CHAPさんというError属性人がすぐに前のAccess-廃棄物パケットに含まれている場合にだけ、含められているでしょうに、そして、CHAP Error属性さんのString分野は、ユーザパスワードが期限が切れたのを示しました、そして、さん-CHAPバージョンは2と等しいです。
A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The fields are transmitted from left to right.
さん-CHAP-CPW-2 Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn Informational [Page 8] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[8ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Code | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old-NT-Hash
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-NT-Hash (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-NT-Hash (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-NT-Hash (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old-LM-Hash
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-LM-Hash(cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-LM-Hash(cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Old-LM-Hash(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Response (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| コード| Ident| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 古い..ハッシュ..古い..ハッシュ..古い..ハッシュ..古い..ハッシュ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 古い..ハッシュ..古い..ハッシュ..古い..ハッシュ..古い..ハッシュ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LM-Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LM-Response (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NT-Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zorn Informational [Page 9] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[9ページ]のRFC2548マイクロソフト
Vendor-Type
4 for MS-CHAP-PW-2
やつPW-2さんのためのベンダータイプ4
Vendor-Length
86
ベンダー長さの86
Code
6
コード6
Ident
The Ident field is one octet and aids in matching requests and
replies. The value of this field MUST be identical to that in the
Ident field in all instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-
Enc-PW and MS-CHAP-PW-2 attributes contained in a single Access-
Request packet.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。 この分野の値はさん-CHAP-LM-Enc-PW(単一のAccessリクエスト・パケットに含まれたさん-CHAP-NT- Enc-PWとさん-CHAP-PW-2属性)のすべてのインスタンスにおけるIdent分野がそれと同じであるに違いありません。
Old-NT-Hash
The Old-NT-Hash field is 16 octets in length. It contains the old
Windows NT password hash encrypted with the new Windows NT
password hash.
Old-NT-ハッシュがさばく古いNTハッシュは長さが16の八重奏です。 それは新しいWindows NTパスワードハッシュで暗号化された古いWindows NTパスワードハッシュを含んでいます。
Old-LM-Hash
The Old-LM-Hash field is 16 octets in length. It contains the old
Lan Manager password hash encrypted with the new Windows NT
password hash.
Old-LM-ハッシュがさばく古いLMハッシュは長さが16の八重奏です。 それは新しいWindows NTパスワードハッシュで暗号化された古いランマネージャパスワードハッシュを含んでいます。
LM-Response
The LM-Response field is 24 octets in length and holds an encoded
function of the password and the received challenge. If this
field is empty, it SHOULD be zero-filled.
LM-応答がさばくLM-応答は、長さにおける24の八重奏であり、パスワードのコード化された機能と容認された挑戦を保持します。 分野はこれであるなら人影がなく、それはSHOULDです。無いっぱいにされてください。
NT-Response
The NT-Response field is 24 octets in length and holds an encoded
function of the password and the received challenge. If this
field is empty, it SHOULD be zero-filled.
NT-応答がさばくNT-応答は、長さにおける24の八重奏であり、パスワードのコード化された機能と容認された挑戦を保持します。 分野はこれであるなら人影がなく、それはSHOULDです。無いっぱいにされてください。
Flags
The Flags field is two octets in length. If the least significant
bit (bit 0) of this field is one, the NT-Response field is to be
used in preference to the LM-Response field for authentication.
The LM-Response field MAY still be used (if present), but the NT-
Response SHOULD be tried first. If least significant bit of the
field is zero, the NT-Response field MUST be ignored and the LM-
Response field used instead. If bit 1 of the Flags field is one,
the Old-LM-Hash field is valid and SHOULD be used. If this bit is
set, at least one instance of the MS-CHAP-LM-Enc-PW attribute MUST
be included in the packet.
Flagsがさばく旗は長さが2つの八重奏です。 この分野の最下位ビット(ビット0)が1であるなら、NT-応答分野は認証のためのLM-応答分野に優先して使用されることです。 LM-応答分野は、まだ中古、そして、(現在)であるかもしれなく、唯一のNT応答はSHOULDです。最初に、試みられます。 分野の最下位ビットはゼロ、NT-応答分野を無視しなければならないということであるかどうか、そして、代わりに使用されるLM応答分野。 Old-LM-ハッシュ分野がFlags分野のビット1が1であるなら、有効である、SHOULD、使用されてください。 このビットが設定されるなら、パケットにさん-CHAP-LM-Enc-PW属性の少なくとも1つのインスタンスを含まなければなりません。
Zorn Informational [Page 10] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[10ページ]のRFC2548マイクロソフト
2.1.8. MS-CHAP-LM-Enc-PW
2.1.8. やつLM-Enc-PWさん
Description
記述
This Attribute contains the new Windows NT password encrypted with
the old LAN Manager password hash. The encrypted Windows NT
password is 516 octets in length; since this is longer than the
maximum lengtth of a RADIUS attribute, the password must be split
into several attibutes for transmission. A 2 octet sequence
number is included in the attribute to help preserve ordering of
the password fragments.
このAttributeは古いLANマネージャパスワードハッシュで暗号化された新しいWindows NTパスワードを含んでいます。 暗号化されたWindows NTパスワードは長さが516の八重奏です。 これがRADIUS属性の最大のlengtthより長いので、トランスミッションのためにパスワードを数個のattibutesに分けなければなりません。 2八重奏一連番号は、パスワード断片の注文を保存するのを助けるために属性に含まれています。
This Attribute is only used in Access-Request packets, in
conjunction with the MS-CHAP-CPW-2 attribute. It should only be
included if an MS-CHAP-Error attribute was included in the
immediately preceding Access-Reject packet, the String field of
the MS-CHAP-Error attribute indicated that the user password had
expired, and the MS-CHAP version is 2 or greater.
このAttributeはAccess-リクエスト・パケットでさん-CHAP-CPW-2属性に関連して使用されるだけです。 CHAPさんというError属性人がすぐに前のAccess-廃棄物パケットに含まれている場合にだけ、それは含まれているでしょうに、そして、CHAP Error属性さんのString分野は、ユーザパスワードが期限が切れたのを示しました、そして、さん-CHAPバージョンは2以上です。
A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. The fields are transmitted from left to right.
さん-CHAP-LM-Enc-PW Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Code | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence-Number | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| コード| Ident| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
5 for MS-CHAP-LM-Enc-PW
やつLM-Enc-PWさんのためのベンダータイプ5
Vendor-Length
> 6
ベンダー長さの>6
Code 6. Code is the same as for the MS-CHAP-PW-2 attribute.
6をコード化してください。 コードはさん-CHAP-PW-2属性のように同じです。
Ident
The Ident field is one octet and aids in matching requests and
replies. The value of this field MUST be identical in all
instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
CHAP-PW-2 attributes which are present in the same Access-Request
packet.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。 この分野の値は同じAccess-リクエスト・パケットでさん-CHAP-LM-Enc-PW、さん-CHAP-NT-Enc-PW、および存在している属性のCHAP-PW-2さんのすべてのインスタンスが同じであるに違いありません。
Zorn Informational [Page 11] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[11ページ]のRFC2548マイクロソフト
Sequence-Number
The Sequence-Number field is two octets in length and indicates
which "chunk" of the encrypted password is contained in the
following String field.
Sequence-ナンバーフィールドに系列で付番してください。以下のString分野に保管されていた状態で長さにおける2つの八重奏であり、暗号化されたパスワードの「塊」がどれであるかを示します。
String The String field contains a portion of the encrypted password.
Stringがさばくストリングは暗号化されたパスワードの部分を含んでいます。
2.2. MS-CHAP-NT-Enc-PW
2.2. やつNT-Enc-PWさん
Description
記述
This Attribute contains the new Windows NT password encrypted with
the old Windows NT password hash. The encrypted Windows NT
password is 516 octets in length; since this is longer than the
maximum lengtth of a RADIUS attribute, the password must be split
into several attibutes for transmission. A 2 octet sequence
number is included in the attribute to help preserve ordering of
the password fragments.
このAttributeは古いWindows NTパスワードハッシュで暗号化された新しいWindows NTパスワードを含んでいます。 暗号化されたWindows NTパスワードは長さが516の八重奏です。 これがRADIUS属性の最大のlengtthより長いので、トランスミッションのためにパスワードを数個のattibutesに分けなければなりません。 2八重奏一連番号は、パスワード断片の注文を保存するのを助けるために属性に含まれています。
This Attribute is only used in Access-Request packets, in conjunc-
tion with the MS-CHAP-CPW-2 and MS-CHAP2-CPW attributes. It
should only be included if an MS-CHAP-Error attribute was included
in the immediately preceding Access-Reject packet, the String
field of the MS-CHAP-Error attribute indicated that the user
password had expired, and the MS-CHAP version is 2 or greater.
このAttributeはAccess-リクエスト・パケット、さん-CHAP-CPW-2とさん-CHAP2-CPW属性があるconjunc- tionで使用されるだけです。 CHAPさんというError属性人がすぐに前のAccess-廃棄物パケットに含まれている場合にだけ、それは含まれているでしょうに、そして、CHAP Error属性さんのString分野は、ユーザパスワードが期限が切れたのを示しました、そして、さん-CHAPバージョンは2以上です。
A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. The fields are transmitted from left to right.
さん-CHAP-NT-Enc-PW Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Code | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence-Number | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| コード| Ident| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
6 for MS-CHAP-NT-Enc-PW
やつNT-Enc-PWさんのためのベンダータイプ6
Vendor-Length
> 6
ベンダー長さの>6
Code
6. Code is the same as for the MS-CHAP-PW-2 attribute.
6をコード化してください。 コードはさん-CHAP-PW-2属性のように同じです。
Zorn Informational [Page 12] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[12ページ]のRFC2548マイクロソフト
Ident
The Ident field is one octet and aids in matching requests and
replies. The value of this field MUST be identical in all
instances of the MS-CHAP-LM-Enc-PW, MS-CHAP-NT-Enc-PW and MS-
CHAP-PW-2 attributes which are present in the same Access-Request
packet.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。 この分野の値は同じAccess-リクエスト・パケットでさん-CHAP-LM-Enc-PW、さん-CHAP-NT-Enc-PW、および存在している属性のCHAP-PW-2さんのすべてのインスタンスが同じであるに違いありません。
Sequence-Number
The Sequence-Number field is two octets in length and indicates
which "chunk" of the encrypted password is contained in the
following String field.
Sequence-ナンバーフィールドに系列で付番してください。以下のString分野に保管されていた状態で長さにおける2つの八重奏であり、暗号化されたパスワードの「塊」がどれであるかを示します。
String
The String field contains a portion of the encrypted password.
Stringがさばくストリングは暗号化されたパスワードの部分を含んでいます。
2.3. Attributes for Support of MS-CHAP Version 2
2.3. やつVersionさん2のサポートのための属性
2.3.1. Introduction
2.3.1. 序論
This section describes RADIUS attributes supporting version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1) [4]. Certain protocol fields have been deleted or reused but with different semantics. Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences between MS-CHAP-V2 and MS-CHAP-V1 are:
このセクションはマイクロソフトのPPP CHAP方言(さん-CHAP-V2)[14]のバージョンtwoをサポートするRADIUS属性について説明します。 さん-CHAP-V2がそうである、同様の、しかし、非互換なさん-CHAPバージョン1(さん-CHAP-V1)[4] ある一定のプロトコル分野が削除されるか、再利用されますが、異なった意味論と共にありました。 可能であるところでは、さん-CHAP-V2がさん-CHAP-V1と標準のCHAP[1]の両方と一致しています。 簡潔に、さん-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-パスワードパケットに取り替えました。
Zorn Informational [Page 13] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[13ページ]のRFC2548マイクロソフト
The attributes defined in this section reflect these differences.
このセクションで定義された属性はこれらの違いを反映します。
2.3.2. MS-CHAP2-Response
2.3.2. CHAP2Responseさん
Description
記述
This Attribute contains the response value provided by an MS-
CHAP-V2 peer in response to the challenge. It is only used in
Access-Request packets.
このAttributeは挑戦に対応してCHAP-V2さんという同輩人によって提供された応答値を含んでいます。 それはAccess-リクエスト・パケットで使用されるだけです。
A summary of the MS-CHAP2-Response Attribute format is shown below. The fields are transmitted from left to right.
CHAP2Response Attribute形式さんの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Ident | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-Challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Ident| 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同輩..挑戦..同輩..挑戦..同輩..挑戦..同輩..挑戦| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約された+++++++++++++++++++++++++++++++++は(cont)を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Response (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
25 for MS-CHAP2-Response.
CHAP2Responseさんのための25をベンダーでタイプしてください。
Vendor-Length
52
ベンダー長さの52
Zorn Informational [Page 14] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[14ページ]のRFC2548マイクロソフト
Ident
Identical to the PPP MS-CHAP v2 Identifier.
PPP MS-CHAP v2 IdentifierへのIdent Identical。
Flags
The Flags field is one octet in length. It is reserved for future
use and MUST be zero.
Flagsがさばく旗は長さが1つの八重奏です。 それは、今後の使用のために予約されて、ゼロであるに違いありません。
Peer-Challenge
The Peer-Challenge field is a 16-octet random number.
Peer-挑戦がさばく同輩挑戦は16八重奏の乱数です。
Reserved
This field is reserved for future use and MUST be zero.
予約されたThis分野は、今後の使用のために予約されて、ゼロであるに違いありません。
Response
The Response field is 24 octets in length and holds an encoded
function of the password, the Peer-Challenge field and the
received challenge.
Responseがさばく応答は、長さにおける24の八重奏であり、パスワードのコード化された機能、Peer-挑戦分野、および容認された挑戦を保持します。
2.3.3. MS-CHAP2-Success
2.3.3. CHAP2Successさん
Description
記述
This Attribute contains a 42-octet authenticator response string.
This string MUST be included in the Message field of the MS-CHAP-
V2 Success packet sent from the NAS to the peer. This Attribute
is only used in Access-Accept packets.
このAttributeは42八重奏の固有識別文字応答ストリングを含んでいます。 NASから同輩に送られたさん-CHAP- V2 SuccessパケットのMessage分野にこのストリングを含まなければなりません。 このAttributeはAccess受け入れているパケットで使用されるだけです。
A summary of the MS-CHAP2-Success Attribute format is shown below. The fields are transmitted from left to right.
CHAP2Success Attribute形式さんの概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Ident | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Ident| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
26 for MS-CHAP2-Success.
CHAP2Successさんのための26をベンダーでタイプしてください。
Vendor-Length
45
ベンダー長さの45
Ident
Identical to the PPP MS-CHAP v2 Identifier.
PPP MS-CHAP v2 IdentifierへのIdent Identical。
String
The 42-octet authenticator string (see above).
42八重奏の固有識別文字ストリングを結んでください(上を見てください)。
Zorn Informational [Page 15] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[15ページ]のRFC2548マイクロソフト
2.3.4. MS-CHAP2-CPW
2.3.4. さん-CHAP2-CPW
Description
記述
This Attribute allows the user to change their password if it has
expired. This Attribute is only used in conjunction with the MS-
CHAP-NT-Enc-PW attribute in Access-Request packets, and should
only be included if an MS-CHAP-Error attribute was included in the
immediately preceding Access-Reject packet, the String field of
the MS-CHAP-Error attribute indicated that the user password had
expired, and the MS-CHAP version is equal to 3.
期限が切れたなら、このAttributeはユーザにそれらのパスワードを変えさせます。 このAttributeはAccess-リクエスト・パケットのCHAP-NT-Enc-PW属性さんに関連して使用されるだけであり、CHAPさんというError属性人がすぐに前のAccess-廃棄物パケットに含まれている場合にだけ、含められているでしょうに、そして、CHAP Error属性さんのString分野は、ユーザパスワードが期限が切れたのを示しました、そして、さん-CHAPバージョンは3と等しいです。
A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The fields are transmitted from left to right.
さん-CHAP-CPW-2 Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Zorn Informational [Page 16] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[16ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Code | Ident |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted-Hash
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted-Hash (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted-Hash (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted-Hash (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-Challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peer-Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-Response
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Response (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| コード| Ident| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 暗号化..ハッシュ..暗号化..ハッシュ..暗号化..ハッシュ..暗号化..ハッシュ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer-Challenge +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer-Challenge (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer-Challenge (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer-Challenge (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer-Challenge (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer-Challenge (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NT-Response +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--++-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NT-Response (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
27 for MS-CHAP2-PW
さん-CHAP2-PWのためのベンダータイプ27
Vendor-Length
70
ベンダー長さの70
Code
7
コード7
Zorn Informational [Page 17] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[17ページ]のRFC2548マイクロソフト
Ident
The Ident field is one octet and aids in matching requests and
replies. The value of this field MUST be identical to that in the
Ident field in all instances of the MS-CHAP-NT-Enc-PW contained in
the Access-Request packet.
Ident、Ident分野は、合っている要求と回答で1つの八重奏と援助です。 この分野の値はAccess-リクエスト・パケットに含まれたさん-CHAP-NT-Enc-PWのすべてのインスタンスにおけるIdent分野がそれと同じであるに違いありません。
Encrypted-Hash
The Encrypted-Hash field is 16 octets in length. It contains the
old Windows NT password hash encrypted with the new Windows NT
password hash.
Encrypted-ハッシュがさばく暗号化されたハッシュは長さが16の八重奏です。 それは新しいWindows NTパスワードハッシュで暗号化された古いWindows NTパスワードハッシュを含んでいます。
NT-Response
The NT-Response field is 24 octets in length and holds an encoded
function of the new password, the Peer-Challenge field and the
received challenge.
NT-応答がさばくNT-応答は、長さにおける24の八重奏であり、新しいパスワードのコード化された機能、Peer-挑戦分野、および容認された挑戦を保持します。
Flags
The Flags field is two octets in length. This field is reserved
for future use and MUST be zero.
Flagsがさばく旗は長さが2つの八重奏です。 この分野は、今後の使用のために予約されて、ゼロであるに違いありません。
2.4. Attributes for MPPE Support
2.4. MPPEサポートのための属性
This section describes a set of Attributes designed to support the use of Microsoft Point-to-Point Encryption (MPPE) [6] in dial-up networks. MPPE is a means of representing Point to Point Protocol (PPP) [7] packets in a encrypted form. MPPE uses the RSA RC4 [8] algorithm for encryption. The length of the session key to be used for initializing encryption tables can be negotiated; MPPE currently supports 40 bit and 128 bit session keys. MPPE is negotiated within option 18 in the PPP Compression Control Protocol (CCP)[9], [10].
このセクションはダイアルアップ・ネットワークにおけるマイクロソフトPointからポイントへのEncryption(MPPE)[6]の使用をサポートするように設計されたAttributesの1セットについて説明します。 MPPEは暗号化されたフォームにPointプロトコル(PPP)[7]パケットにPointを表す手段です。 MPPEは暗号化にRSA RC4[8]アルゴリズムを使用します。 初期値設定暗号化テーブルにおいて使用されているために主要なセッションの長さを交渉できます。 MPPEは、現在、40ビットと128ビットがセッションキーであるとサポートします。 MPPEはPPP Compression Controlプロトコル(CCP)[9]、[10]のオプション18の中で交渉されます。
2.4.1. MS-CHAP-MPPE-Keys
2.4.1. やつMPPE Keysさん
Description
記述
The MS-CHAP-MPPE-Keys Attribute contains two session keys for use
by the Microsoft Point-to-Point Encryption Protocol (MPPE). This
Attribute is only included in Access-Accept packets.
マイクロソフトPointからポイントへのEncryptionプロトコル(MPPE)でCHAP-MPPEキーズAttributeさんは使用のための2個のセッションキーを含みます。 このAttributeはAccess受け入れているパケットに含まれているだけです。
A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. The fields are transmitted left to right.
CHAP-MPPE Keys Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 18] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[18ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Keys
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Keys (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Keys +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Keys (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
12 for MS-CHAP-MPPE-Keys.
やつMPPE Keysさんのための12をベンダーでタイプしてください。
Vendor-Length
34
ベンダー長さの34
Keys
The Keys field consists of two logical sub-fields: the LM-Key and
the NT-Key. The LM-Key is eight octets in length and contains the
first eight bytes of the output of the function LmPasswordHash(P,
This hash is constructed as follows: let the plain-text password
be represented by P.
キーズがさばくキーは2つの論理的なサブ分野から成ります: LM-キーとNT-キー。 LM主要は、長さにおける8つの八重奏であり、機能LmPasswordHashの出力の最初の8バイトを含んでいます。(P、Thisハッシュは以下の通り構成されます:、Pでプレーンテキストパスワードを表させてください。
The NT-Key sub-field is sixteen octets in length and contains the
first sixteen octets of the hashed Windows NT password. The
format of the plaintext Keys field is illustrated in the following
diagram:
NT主要なサブ分野は、長さにおける16の八重奏であり、論じ尽くされたWindows NTパスワードの最初の16の八重奏を含んでいます。 平文キーズ分野の形式は以下のダイヤグラムで例証されます:
Zorn Informational [Page 19] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[19ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LM-Key
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LM-Key (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NT-Key
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Key (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Key (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NT-Key (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Padding (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LM主要な++++++++++++++++++++++++++++++++LM主要な(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要..主要..主要..主要| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont)を水増ししながら、++++++++++++++++++++++++++++++++を水増しします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Keys field MUST be encrypted by the RADIUS server using the
same method defined for the User-Password Attribute [3]. Padding
is required because the method referenced above requires the field
to be encrypted to be a multiple of sixteen octets in length.
User-パスワードAttribute[3]のために定義された同じメソッドを使用して、RADIUSサーバでキーズ分野を暗号化しなければなりません。 上で参照をつけられたメソッドが、分野が長さにおける、16の八重奏の倍数になるように暗号化されるのを必要とするので、詰め物が必要です。
Implementation Note
This attribute should only be returned in response to an
Access-Request packet containing MS-CHAP attributes.
さん-CHAP属性を含んでいて、実装Note This属性はAccess-リクエスト・パケットに対応して返されるだけであるべきです。
2.4.2. MS-MPPE-Send-Key
2.4.2. MPPEさんはキーを送ります。
Description
記述
The MS-MPPE-Send-Key Attribute contains a session key for use by
the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
name implies, this key is intended for encrypting packets sent
from the NAS to the remote host. This Attribute is only included
in Access-Accept packets.
MPPEさんがキーを送っているAttributeは使用に、マイクロソフトPointからポイントへのEncryptionプロトコル(MPPE)で主要なセッションを含んでいます。 名前が含意するように、このキーはNASからリモートホストに送られたパケットを暗号化するために意図します。 このAttributeはAccess受け入れているパケットに含まれているだけです。
A summary of the MS-MPPE-Send-Key Attribute format is given below. The fields are transmitted left to right.
MPPEさんがキーを送っているAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 20] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[20ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| +++++++++++++++++++++++++++++++++ストリングの塩で処理をしてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
16 for MS-MPPE-Send-Key.
MPPEがキーを送るさんのための16をベンダーでタイプしてください。
Vendor-Length
> 4
ベンダー長さの>4
Salt
The Salt field is two octets in length and is used to ensure the
uniqueness of the keys used to encrypt each of the encrypted
attributes occurring in a given Access-Accept packet. The most
significant bit (leftmost) of the Salt field MUST be set (1). The
contents of each Salt field in a given Access-Accept packet MUST
be unique.
Saltがさばく塩は、長さにおける2つの八重奏であり、キーのユニークさが以前はよく与えられたAccess受け入れているパケットに起こるそれぞれの暗号化された属性を暗号化していたのを保証するのに使用されます。 Salt分野の最も重要なビット(一番左)はセット(1)であるに違いない。 与えられたAccess受け入れているパケットのそれぞれのSalt分野のコンテンツはユニークであるに違いありません。
String
The plaintext String field consists of three logical sub-fields:
the Key-Length and Key sub-fields (both of which are required),
and the optional Padding sub-field. The Key-Length sub-field is
one octet in length and contains the length of the unencrypted Key
sub-field. The Key sub-field contains the actual encryption key.
If the combined length (in octets) of the unencrypted Key-Length
and Key sub-fields is not an even multiple of 16, then the Padding
sub-field MUST be present. If it is present, the length of the
Padding sub-field is variable, between 1 and 15 octets. The
String field MUST be encrypted as follows, prior to transmission:
平文Stringがさばくストリングは3つの論理的なサブ分野から成ります: Key-長さ、Keyサブ分野(それの両方が必要である)、および任意のPaddingサブ分野。 Key-長さのサブ分野は、長さにおける1つの八重奏であり、unencrypted Keyサブ分野の長さを含んでいます。 Keyサブ分野は実際の暗号化キーを含んでいます。 unencrypted Key-長さとKeyサブ分野の結合した長さ(八重奏における)が16の同等の倍数でないなら、Paddingサブ分野は存在していなければなりません。 それが存在しているなら、Paddingサブ分野の長さは変数、1〜15の八重奏です。 トランスミッションの前に以下の通りString分野を暗号化しなければなりません:
Construct a plaintext version of the String field by concate-
nating the Key-Length and Key sub-fields. If necessary, pad
the resulting string until its length (in octets) is an even
multiple of 16. It is recommended that zero octets (0x00) be
used for padding. Call this plaintext P.
サブ分野でString分野のconcate- natingによるKey-長さとKeyの平文バージョンを構成してください。 必要なら、長さ(八重奏における)が16の同等の倍数になるまで結果として起こるストリングを水増ししてください。 八重奏(0×00)が全く詰め物に使用されないのは、お勧めです。 Pにこの平文に電話をしてください。
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required. Encryption
is performed in the following manner ('+' indicates
concatenation):
分野A.Break Pを共有秘密キーS、擬似ランダム128ビットのRequest Authenticator(対応するAccess-リクエスト・パケットからの)R、およびSaltのコンテンツに16八重奏塊p(1)に電話をしてください、p(2)…p(i)。(そこでは、iがlen(P)/16と等しいです)。 暗号文ブロックをc(1)、c(2)と呼んでください…c(i)と最終的な暗号文C.Intermediateはb(1)、b(2)を評価します…c(i)が必要です。 暗号化は以下の方法で実行されます('+'は連結を示します):
Zorn Informational [Page 21] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[21ページ]のRFC2548マイクロソフト
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
b(1)がMD5と等しい、(S+R+a)c(1)=p(1) xor b(1)C=c(1) b(2)がMD5と等しい、(S+c(1)) c(2)=p(2) xor b(2)CはC+c(2)と等しいです… b(i)=MD5(S+c(i-1))c(i)=p(i) xor b(i)CはC+cと等しいです。(i)
The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).
結果として起こる暗号化されたString分野はc(1)+c(2)+を含むでしょう…+ c(i)。
On receipt, the process is reversed to yield the plaintext String.
領収書の上では、プロセスは、平文Stringをもたらすために逆にされます。
Implementation Notes
It is possible that the length of the key returned may be larger
than needed for the encryption scheme in use. In this case, the
RADIUS client is responsible for performing any necessary
truncation.
実装Notes Itは返されたキーの長さが暗号化体系に使用中に必要とされるより大きいかもしれないのが可能です。 この場合、RADIUSクライアントはどんな必要なトランケーションも実行するのに責任があります。
This attribute MAY be used to pass a key from an external (e.g.,
EAP [15]) server to the RADIUS server. In this case, it may be
impossible for the external server to correctly encrypt the key,
since the RADIUS shared secret might be unavailable. The external
server SHOULD, however, return the attribute as defined above; the
Salt field SHOULD be zero-filled and padding of the String field
SHOULD be done. When the RADIUS server receives the attribute
from the external server, it MUST correctly set the Salt field and
encrypt the String field before transmitting it to the RADIUS
client. If the channel used to communicate the MS-MPPE-Send-Key
attribute is not secure from eavesdropping, the attribute MUST be
cryptographically protected.
この属性が外部からキーを渡すのに使用されるかもしれない、(例えば、EAP[15])サーバ、サーバこの場合それがそうするRADIUSに、外部のサーバが正しくキーを暗号化するのは、不可能にしてください、RADIUS共有秘密キーが入手できないかもしれないので。 しかしながら、外部のサーバSHOULDは上で定義されるように属性を返します。 無いっぱいにされて、SaltはSHOULDをさばきます、そして、String分野SHOULDを水増しして、してください。 RADIUSサーバが外部のサーバから属性を受けるとき、RADIUSクライアントにそれを伝える前に、それは、正しくSalt分野を設定して、String分野を暗号化しなければなりません。 MPPEさんがキーを送っている属性を伝えるのに使用されるチャンネルが盗聴から安全でないなら、暗号で属性を保護しなければなりません。
2.4.3. MS-MPPE-Recv-Key
2.4.3. MPPE-Recv Keyさん
Description
記述
The MS-MPPE-Recv-Key Attribute contains a session key for use by
the Microsoft Point-to-Point Encryption Protocol (MPPE). As the
name implies, this key is intended for encrypting packets received
by the NAS from the remote host. This Attribute is only included
in Access-Accept packets.
マイクロソフトPointからポイントへのEncryptionプロトコル(MPPE)によるAttributeがセッションキーを含むMPPE-Recv Key使用さん。 名前が含意するように、このキーはNASによってリモートホストから受け取られたパケットを暗号化するために意図します。 このAttributeはAccess受け入れているパケットに含まれているだけです。
A summary of the MS-MPPE-Recv-Key Attribute format is given below. The fields are transmitted left to right.
MPPE-Recv Key Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 22] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[22ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| +++++++++++++++++++++++++++++++++ストリングの塩で処理をしてください… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
17 for MS-MPPE-Recv-Key.
MPPE-Recv Keyさんのための17をベンダーでタイプしてください。
Vendor-Length
> 4
ベンダー長さの>4
Salt
The Salt field is two octets in length and is used to ensure the
uniqueness of the keys used to encrypt each of the encrypted
attributes occurring in a given Access-Accept packet. The most
significant bit (leftmost) of the Salt field MUST be set (1). The
contents of each Salt field in a given Access-Accept packet MUST
be unique.
Saltがさばく塩は、長さにおける2つの八重奏であり、キーのユニークさが以前はよく与えられたAccess受け入れているパケットに起こるそれぞれの暗号化された属性を暗号化していたのを保証するのに使用されます。 Salt分野の最も重要なビット(一番左)はセット(1)であるに違いない。 与えられたAccess受け入れているパケットのそれぞれのSalt分野のコンテンツはユニークであるに違いありません。
String
The plaintext String field consists of three logical sub-fields:
the Key-Length and Key sub-fields (both of which are required),
and the optional Padding sub-field. The Key-Length sub-field is
one octet in length and contains the length of the unencrypted Key
sub-field. The Key sub-field contains the actual encryption key.
If the combined length (in octets) of the unencrypted Key-Length
and Key sub-fields is not an even multiple of 16, then the Padding
sub-field MUST be present. If it is present, the length of the
Padding sub-field is variable, between 1 and 15 octets. The
String field MUST be encrypted as follows, prior to transmission:
平文Stringがさばくストリングは3つの論理的なサブ分野から成ります: Key-長さ、Keyサブ分野(それの両方が必要である)、および任意のPaddingサブ分野。 Key-長さのサブ分野は、長さにおける1つの八重奏であり、unencrypted Keyサブ分野の長さを含んでいます。 Keyサブ分野は実際の暗号化キーを含んでいます。 unencrypted Key-長さとKeyサブ分野の結合した長さ(八重奏における)が16の同等の倍数でないなら、Paddingサブ分野は存在していなければなりません。 それが存在しているなら、Paddingサブ分野の長さは変数、1〜15の八重奏です。 トランスミッションの前に以下の通りString分野を暗号化しなければなりません:
Construct a plaintext version of the String field by
concatenating the Key-Length and Key sub-fields. If necessary,
pad the resulting string until its length (in octets) is an
even multiple of 16. It is recommended that zero octets (0x00)
be used for padding. Call this plaintext P.
Key-長さとKeyサブ分野を連結することによって、String分野の平文バージョンを構成してください。 必要なら、長さ(八重奏における)が16の同等の倍数になるまで結果として起こるストリングを水増ししてください。 八重奏(0×00)が全く詰め物に使用されないのは、お勧めです。 Pにこの平文に電話をしてください。
Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required. Encryption
is performed in the following manner ('+' indicates
concatenation):
分野A.Break Pを共有秘密キーS、擬似ランダム128ビットのRequest Authenticator(対応するAccess-リクエスト・パケットからの)R、およびSaltのコンテンツに16八重奏塊p(1)に電話をしてください、p(2)…p(i)。(そこでは、iがlen(P)/16と等しいです)。 暗号文ブロックをc(1)、c(2)と呼んでください…c(i)と最終的な暗号文C.Intermediateはb(1)、b(2)を評価します…c(i)が必要です。 暗号化は以下の方法で実行されます('+'は連結を示します):
Zorn Informational [Page 23] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[23ページ]のRFC2548マイクロソフト
b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
b(1)がMD5と等しい、(S+R+a)c(1)=p(1) xor b(1)C=c(1) b(2)がMD5と等しい、(S+c(1)) c(2)=p(2) xor b(2)CはC+c(2)と等しいです… b(i)=MD5(S+c(i-1))c(i)=p(i) xor b(i)CはC+cと等しいです。(i)
The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).
結果として起こる暗号化されたString分野はc(1)+c(2)+を含むでしょう…+ c(i)。
On receipt, the process is reversed to yield the plaintext String.
領収書の上では、プロセスは、平文Stringをもたらすために逆にされます。
Implementation Notes
It is possible that the length of the key returned may be larger
than needed for the encryption scheme in use. In this case, the
RADIUS client is responsible for performing any necessary
truncation.
実装Notes Itは返されたキーの長さが暗号化体系に使用中に必要とされるより大きいかもしれないのが可能です。 この場合、RADIUSクライアントはどんな必要なトランケーションも実行するのに責任があります。
This attribute MAY be used to pass a key from an external (e.g.,
EAP [15]) server to the RADIUS server. In this case, it may be
impossible for the external server to correctly encrypt the key,
since the RADIUS shared secret might be unavailable. The external
server SHOULD, however, return the attribute as defined above; the
Salt field SHOULD be zero-filled and padding of the String field
SHOULD be done. When the RADIUS server receives the attribute
from the external server, it MUST correctly set the Salt field and
encrypt the String field before transmitting it to the RADIUS
client. If the channel used to communicate the MS-MPPE-Recv-Key
attribute is not secure from eavesdropping, the attribute MUST be
cryptographically protected.
この属性が外部からキーを渡すのに使用されるかもしれない、(例えば、EAP[15])サーバ、サーバこの場合それがそうするRADIUSに、外部のサーバが正しくキーを暗号化するのは、不可能にしてください、RADIUS共有秘密キーが入手できないかもしれないので。 しかしながら、外部のサーバSHOULDは上で定義されるように属性を返します。 無いっぱいにされて、SaltはSHOULDをさばきます、そして、String分野SHOULDを水増しして、してください。 RADIUSサーバが外部のサーバから属性を受けるとき、RADIUSクライアントにそれを伝える前に、それは、正しくSalt分野を設定して、String分野を暗号化しなければなりません。 MPPE-Recv Key属性さんを伝えるのに使用されるチャンネルが盗聴から安全でないなら、暗号で属性を保護しなければなりません。
2.4.4. MS-MPPE-Encryption-Policy
2.4.4. MPPE Encryption Policyさん
Description
記述
The MS-MPPE-Encryption-Policy Attribute may be used to signify
whether the use of encryption is allowed or required. If the
Policy field is equal to 1 (Encryption-Allowed), any or none of
the encryption types specified in the MS-MPPE-Encryption-Types
Attribute MAY be used. If the Policy field is equal to 2
(Encryption-Required), any of the encryption types specified in
the MS-MPPE-Encryption-Types Attribute MAY be used, but at least
one MUST be used.
MPPE Encryption Policy Attributeさんは、暗号化の使用が許容されているか、または必要であることにかかわらず意味するのに使用されるかもしれません。 Policy分野が等しいなら、MPPE暗号化タイプさんで指定された暗号化タイプの1(暗号化で許容された)、いずれまたはだれにも、Attributeは使用されないかもしれません。 Policy分野が等しいなら、2(暗号化で必要な)、MPPE暗号化タイプさんで指定された暗号化タイプのどれかに、Attributeは使用されるかもしれませんが、少なくとも使用しなければなりません。
A summary of the MS-MPPE-Encryption-Policy Attribute format is given below. The fields are transmitted left to right.
MPPE Encryption Policy Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 24] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[24ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Policy
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Policy (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 方針+++++++++++++++++++++++++++++++++方針(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
7 for MS-MPPE-Encryption-Policy.
MPPE Encryption Policyさんのための7をベンダーでタイプしてください。
Vendor-Length
6
ベンダー長さの6
Policy
The Policy field is 4 octets in length. Defined values are:
Policyがさばく方針は長さが4つの八重奏です。 定義された値は以下の通りです。
1 Encryption-Allowed 2 Encryption-Required
1は暗号化で必要な状態で2を暗号化で許容しました。
2.4.5. MS-MPPE-Encryption-Types
2.4.5. MPPE暗号化タイプさん
Description
記述
The MS-MPPE-Encryption-Types Attribute is used to signify the
types of encryption available for use with MPPE. It is a four
octet integer that is interpreted as a string of bits.
MPPE暗号化タイプAttributeさんは、MPPEとの使用に利用可能な暗号化のタイプを意味するのに使用されます。 それは一連のビットとして解釈される4八重奏整数です。
A summary of the MS-MPPE-Encryption-Policy Attribute format is given below. The fields are transmitted left to right.
MPPE Encryption Policy Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Types
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Types (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| +++++++++++++++++++++++++++++++++タイプ(cont)をタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
8 for MS-MPPE-Encryption-Types.
MPPE暗号化タイプさんのための8をベンダーでタイプしてください。
Vendor-Length
6
ベンダー長さの6
Policy
The Types field is 4 octets in length. The following diagram
illustrates the Types field.
Typesがさばく方針は長さが4つの八重奏です。 以下のダイヤグラムはTypes分野を例証します。
Zorn Informational [Page 25] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[25ページ]のRFC2548マイクロソフト
3 2 1
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |S|L| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |S|L| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the L bit is set, RC4[5] encryption using a 40-bit key is
allowed. If the S bit is set, RC4 encryption using a 128-bit key
is allowed. If both the L and S bits are set, then either 40- or
128-bit keys may be used with the RC4 algorithm.
Lビットが設定されるなら、40ビットのキーを使用するRC4[5]暗号化が許容されています。 Sビットが設定されるなら、128ビットのキーを使用するRC4暗号化が許容されています。 LとSビットの両方が設定されるなら、40か128ビットのキーのどちらかがRC4アルゴリズムで使用されるかもしれません。
2.5. Attributes for BAP Support
2.5. BAPサポートのための属性
This section describes a set of vendor-specific RADIUS attributes designed to support the dynamic control of bandwidth allocation in multilink PPP [11]. Attributes are defined that specify whether use of the PPP Bandwidth Allocation Protocol (BAP) [12] is allowed or required on incoming calls, the level of line capacity (expressed as a percentage) below which utilization must fall before a link is eligible to be dropped, and the length of time (in seconds) that a link must be under-utilized before it is dropped.
このセクションはマルチリンクPPP[11]の帯域幅配分の動的制御をサポートするように設計された1セットのベンダー特有のRADIUS属性について説明します。 PPP Bandwidth Allocationプロトコル(BAP)[12]の使用がかかってきた電話のときに許容されているか、または必要であるか、そして、リンクが下げられる資格がある前に利用が落下しなければならない線路容量(割合として、言い表される)のレベル、およびそれが下げられる前にリンクが下の利用していなければならないことの時間(秒の)の長さを指定する属性が定義されます。
2.5.1. MS-BAP-Usage
2.5.1. MS BAP用法
Description
記述
This Attribute describes whether the use of BAP is allowed,
disallowed or required on new multilink calls. It MAY be used in
Access-Accept packets.
このAttributeは、BAPの使用が新しいマルチリンク呼び出しのときに許容されているか、禁じられるか、または必要であるかを説明します。 それはAccess受け入れているパケットで使用されるかもしれません。
A summary of the MS-BAP-Usage Attribute format is shown below. The fields are transmitted from left to right.
MS BAP用法Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
13 for MS-BAP-Usage.
MS BAP用法のための13をベンダーでタイプしてください。
Vendor-Length
6
ベンダー長さの6
Zorn Informational [Page 26] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[26ページ]のRFC2548マイクロソフト
Value
The Value field is four octets.
Valueがさばく値は4つの八重奏です。
0 BAP usage not allowed
1 BAP usage allowed
2 BAP usage required
0 2BAP用法が許容された1つのBAP用法が許容されなかったBAP用法が必要です。
2.5.2. MS-Link-Utilization-Threshold
2.5.2. MSリンク利用敷居
Description
記述
This Attribute represents the percentage of available bandwidth
utilization below which the link must fall before the link is
eligible for termination. Permissible values for the MS-Link-
Utilization-Threshold Attribute are in the range 1-100, inclusive.
It is only used in Access-Accept packets.
このAttributeは終了において適任になる前にリンクが落ちなければならない利用可能な帯域幅利用の割合を表します。 利用敷居をリンクしているMS Attributeのための許容値が範囲1-100と、包括的にあります。 それはAccess受け入れているパケットで使用されるだけです。
A summary of the MS-Link-Utilization-Threshold Attribute format is shown below. The fields are transmitted from left to right.
MSリンク利用敷居Attribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
14 for MS-Link-Utilization-Threshold
MSリンク利用敷居のためのベンダータイプ14
Vendor-Length 6
ベンダー長さの6
Value The Value field is four octets in length and represents the
percentage of available bandwidth utilization below which the link
must fall before the link is eligible for termination.
Permissible values are in the range 1-100, inclusive.
Valueがさばく値は、長さにおける4つの八重奏であり、終了において適任になる前にリンクが落ちなければならない利用可能な帯域幅利用の割合を表します。 許容値が範囲1-100と、包括的にあります。
2.5.3. MS-Link-Drop-Time-Limit
2.5.3. MSリンク低下タイムリミット
Description
記述
The MS-Link-Drop-Time-Limit Attribute indicates the length of time
(in seconds) that a link must be underutilized before it is
dropped. It MAY only be included in Access-Accept packets.
MSリンク低下時間限界Attributeは、それの前にリンクをunderutilizedしなければならない時間(秒の)の長さが下げられるのを示します。 それはAccess受け入れているパケットに含まれているだけであるかもしれません。
A summary of the MS-Link-Drop-Time-Limit Attribute format is given below. The fields are transmitted left to right.
MSリンク低下時間限界Attribute形式の概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 27] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[27ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
15 for MS-Link-Drop-Time-Limit
MSリンク低下タイムリミットのためのベンダータイプ15
Vendor-Length
6
ベンダー長さの6
Value
The Value field represents the number of seconds that a link must
be underutilized (i.e., display bandwidth utilization below the
threshold specified in the MS-Link-Utilization-Threshold
Attribute) before the link is dropped.
リンクが下げられる前にValueがさばく値はリンクをunderutilizedしなければならない(すなわち、敷居の下におけるディスプレイ帯域幅利用はMSリンク利用敷居Attributeで指定しました)秒の数を表します。
2.6. Attributes for ARAP Support
2.6. アラップSupportのための属性
This section describes a set of Attributes designed to support the Apple Remote Access Protocol (ARAP).
このセクションはアップルRemote Accessがプロトコル(ARAP)であるとサポートするように設計されたAttributesの1セットについて説明します。
2.6.1. MS-Old-ARAP-Password
2.6.1. MSの古いアラップパスワード
Description
記述
The MS-Old-ARAP-Password Attribute is used to transmit the old
ARAP password during an ARAP password change operation. It MAY be
included in Access-Request packets.
MSの古いARAPパスワードAttributeは、ARAPパスワード変化操作の間、古いARAPパスワードを伝えるのに使用されます。 それはAccess-リクエスト・パケットに含まれるかもしれません。
A summary of the MS-Old-ARAP-Password Attribute Attribute format is given below. The fields are transmitted left to right.
MSの古いARAPパスワードAttribute Attribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
19 for MS-Old-ARAP-Password Attribute
MSの古いアラップパスワード属性のためのベンダータイプ19
Vendor-Length
> 3
ベンダー長さの>3
Zorn Informational [Page 28] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[28ページ]のRFC2548マイクロソフト
String
The String field is one or more octets. It contains the old ARAP
password DES-encrypted using itself as the key.
Stringがさばくストリングは1つ以上の八重奏です。 DESによって暗号化されていた状態で、それは、キーとしてそれ自体を使用することで古いARAPパスワードを含んでいます。
2.6.2. MS-New-ARAP-Password
2.6.2. MSの新しいアラップパスワード
Description
記述
The MS-New-ARAP-Password Attribute is used to transmit the new
ARAP password during an ARAP password change operation. It MAY be
included in Access-Request packets.
MSの新しいARAPパスワードAttributeは、ARAPパスワード変化操作の間、新しいARAPパスワードを伝えるのに使用されます。 それはAccess-リクエスト・パケットに含まれるかもしれません。
A summary of the MS-New-ARAP-Password Attribute Attribute format is given below. The fields are transmitted left to right.
MSの新しいARAPパスワードAttribute Attribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
20 for MS-New-ARAP-Password Attribute
MSの新しいアラップパスワード属性のためのベンダータイプ20
Vendor-Length
> 3
ベンダー長さの>3
String
The String field is one or more octets. It contains the new ARAP
password DES-encrypted using the old ARAP password as the key.
Stringがさばくストリングは1つ以上の八重奏です。 DESによって暗号化されていた状態で、それは、キーとして古いARAPパスワードを使用することで新しいARAPパスワードを含んでいます。
2.6.3. MS-ARAP-Password-Change-Reason
2.6.3. MSアラップパスワード変化理由
Description
記述
The MS-ARAP-Password-Change-Reason Attribute is used to indicate
reason for a server-initiated password change. It MAY be included
in Access-Challenge packets.
ARAPパスワードChange Reason Attributeさんは、サーバで開始しているパスワード変化の理由を示すのに使用されます。 それはAccess-挑戦パケットに含まれるかもしれません。
A summary of the MS-ARAP-Password-Change-Reason Attribute format is given below. The fields are transmitted left to right.
ARAPパスワードChange Reason Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 29] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[29ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Why
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Why (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| なぜ+++++++++++++++++++++++++++++++++なぜ(cont)?| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
21 for MS-ARAP-Password-Change-Reason
MSアラップパスワード変化理由によるベンダータイプ21
Vendor-Length
6
ベンダー長さの6
Why
The Why field is 4 octets in length. The following values are
defined:
Just-Change-Password 1
Expired-Password 2
Admin-Requires-Password-Change 3
Password-Too-Short 4
Why分野は長さが4つの八重奏です。 以下の値は定義されます: 1ただパスワードを変えている満期のパスワード2、3、アドミンがパスワード変化が必要なパスワードもショートしている4
2.6.4. MS-ARAP-Challenge
2.6.4. アラップさんの挑戦
Description
記述
This attribute is only present in an Access-Request packet
containing a Framed-Protocol Attribute with the value 3 (ARAP).
値3(ARAP)があるFramed-プロトコルAttributeを含んでいて、この属性は単にAccess-リクエスト・パケットに存在しています。
A summary of the MS-ARAP-Challenge Attribute format is given below. The fields are transmitted left to right.
ARAP Challenge Attribute形式さんの概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Challenge
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Challenge (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 挑戦+++++++++++++++++++++++++++++++++挑戦(cont)| +++++++++++++++++++++++++++++++++挑戦(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
33 for MS-ARAP-Challenge
アラップさんの挑戦のためのベンダータイプ33
Vendor-Length
10
ベンダー長さの10
Zorn Informational [Page 30] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[30ページ]のRFC2548マイクロソフト
Value
The Challenge Field is 8 octets in length. It contains the
challenge (as two 4-octet quantities) sent by the NAS to the peer.
値、Challenge Fieldは長さが8つの八重奏です。 それはNASによって同輩に送られた挑戦(2つの4八重奏の量としての)を含んでいます。
2.7. Miscellaneous Attributes
2.7. 種々雑多な属性
This section describes attributes which do not fall into any particular category, but are used in the identification and operation of Microsoft remote access products.
このセクションはどんな特定のカテゴリにもなりませんが、マイクロソフトの遠隔アクセスの製品の識別と操作に使用される属性について説明します。
2.7.1. MS-RAS-Vendor
2.7.1. MS RASベンダー
Description
記述
The MS-RAS-Vendor Attribute is used to indicate the manufacturer
of the RADIUS client machine. It MAY be included in both Access-
Request and Accounting-Request packets.
MS RASベンダーAttributeは、RADIUSクライアントマシンのメーカーを示すのに使用されます。 それはAccess要求とAccounting-リクエスト・パケットの両方に含まれるかもしれません。
A summary of the MS-RAS-Vendor Attribute format is given below. The fields are transmitted left to right.
MS RASベンダーAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Vendor-ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-ID (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| ベンダーID+++++++++++++++++++++++++++++++++ベンダーID(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
9 for MS-RAS-Vendor
MS RASベンダーのためのベンダータイプ9
Vendor-Length
6
ベンダー長さの6
Vendor-ID
The Vendor-ID field is 4 octets in length. The high-order octet
is 0 and the low-order 3 octets are the SMI Network Management
Private Enterprise Code of the Vendor in network byte order, as
defined in the Assigned Numbers RFC [13].
Vendor-IDがさばくベンダーIDは長さが4つの八重奏です。 高位八重奏は0です、そして、下位の3つの八重奏がネットワークバイトオーダーにおけるVendorのSMI Network Management兵士のエンタープライズCodeです、Assigned民数記RFC[13]で定義されるように。
2.7.2. MS-RAS-Version
2.7.2. MS RASバージョン
Description
記述
The MS-RAS-Version Attribute is used to indicate the version of
the RADIUS client software. This attribute SHOULD be included in
packets containing an MS-RAS-Vendor Attribute; it SHOULD NOT be
MS RASバージョンAttributeは、RADIUSクライアントソフトウェアのバージョンを示すのに使用されます。 含まれていて、MS RASベンダーAttributeを含んでいて、これはパケットでSHOULDを結果と考えます。 それ、SHOULD NOT
Zorn Informational [Page 31] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[31ページ]のRFC2548マイクロソフト
sent in packets which do not contain an MS-RAS-Vendor Attribute.
It MAY be included in both Access-Request and Accounting-Request
packets.
MS RASベンダーAttributeを含まないパケットを送りました。 それはAccess-要求とAccounting-リクエスト・パケットの両方に含まれるかもしれません。
A summary of the MS-RAS-Version Attribute format is given below. The fields are transmitted left to right.
MS RASバージョンAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| 結びます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
18 for MS-RAS-Version
MS RASバージョンのためのベンダータイプ18
Vendor-Length
> 3
ベンダー長さの>3
String
The String field is one or more octets. The actual format of the
information is vendor specific, and a robust implementation SHOULD
support the field as undistinguished octets.
Stringがさばくストリングは1つ以上の八重奏です。 情報の実際の形式は、ベンダー特有であって、SHOULDが平凡な八重奏として分野をサポートする強健な実装です。
2.7.3. MS-Filter
2.7.3. MS-フィルタ
Description
記述
The MS-Filter Attribute is used to transmit traffic filters. It
MAY be included in both Access-Accept and Accounting-Request
packets.
MS-フィルタAttributeは、トラフィックフィルタを送るのに使用されます。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
If multiple MS-Filter Attributes are contained within a packet,
they MUST be in order and they MUST be consecutive attributes in
the packet.
複数のMS-フィルタAttributesがパケットの中に含まれているなら、彼らは整然とするに違いありません、そして、パケットの連続した属性であるに違いありません。
A summary of the MS-Filter Attribute format is given below. The fields are transmitted left to right.
MS-フィルタAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Filter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| フィルターにかけます。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
22 for MS-Filter Attribute
MS-フィルタ属性のためのベンダータイプ22
Zorn Informational [Page 32] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[32ページ]のRFC2548マイクロソフト
Vendor-Length
> 3
ベンダー長さの>3
Filter
The Filter field is one or more octets. It contains a sequence of
undifferentiated octets.
Filterがさばくフィルタは1つ以上の八重奏です。 それは非差別化された八重奏の系列を含んでいます。
If multiple MS-Filter Attributes occur in a single Access-Accept
packet, the Filter field from each MUST be concatenated in the
order received to form the actual filter.
複数のMS-フィルタAttributesが単一のAccess受け入れているパケットに起こるなら、実際のフィルタを形成するために受注でそれぞれからのFilter分野を連結しなければなりません。
2.7.4. MS-Acct-Auth-Type
2.7.4. MS Acct-Authはタイプします。
Description
記述
The MS-Acct-Auth-Type Attribute is used to represent the method
used to authenticate the dial-up user. It MAY be included in
Accounting-Request packets.
MS Acct-AuthがタイプしているAttributeは、ダイアルアップユーザーを認証するのに使用されるメソッドを表すのに使用されます。 それはAccounting-リクエスト・パケットに含まれるかもしれません。
A summary of the MS-Acct-Auth-Type Attribute format is given below. The fields are transmitted left to right.
MS Acct-AuthがタイプしているAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Auth-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth-Type (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| Auth-タイプ+++++++++++++++++++++++++++++++++Auth-タイプ(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
23 for MS-Acct-Auth-Type
MS Acct-Authタイプのためのベンダータイプ23
Vendor-Length
6
ベンダー長さの6
Auth-Type
The Auth-Type field is 4 octets in length. The following values
are defined for this field:
Auth-タイプがさばくAuth-タイプは長さが4つの八重奏です。 以下の値はこの分野と定義されます:
PAP 1
CHAP 2
MS-CHAP-1 3
MS-CHAP-2 4
EAP 5
乳首1 2やつ1 3やつさんやつEAP5さん2 4
Zorn Informational [Page 33] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[33ページ]のRFC2548マイクロソフト
2.7.5. MS-Acct-EAP-Type
2.7.5. MS Acct-EAPはタイプします。
Description
記述
The MS-Acct-EAP-Type Attribute is used to represent the Extensible
Authentication Protocol (EAP) [15] type used to authenticate the
dial-up user. It MAY be included in Accounting-Request packets.
MS Acct-EAPがタイプしているAttributeは、ダイアルアップユーザーを認証するのに使用される拡張認証プロトコル(EAP)[15]タイプの代理をするのに使用されます。 それはAccounting-リクエスト・パケットに含まれるかもしれません。
A summary of the MS-Acct-EAP-Type Attribute format is given below. The fields are transmitted left to right.
MS Acct-EAPがタイプしているAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | EAP-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EAP-Type (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| EAP-タイプ+++++++++++++++++++++++++++++++++EAP-タイプ(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
24 for MS-Acct-EAP-Type
MS Acct-EAPタイプのためのベンダータイプ24
Vendor-Length
6
ベンダー長さの6
Auth-Type
The EAP-Type field is 4 octets in length. The following values
are currently defined for this field:
EAP-タイプがさばくAuth-タイプは長さが4つの八重奏です。 以下の値は現在、この分野と定義されます:
MD5 4
OTP 5
Generic Token Card 6
TLS 13
MD5 4 OTP5ジェネリックトークン・カード6TLS13
2.7.6. MS-Primary-DNS-Server
2.7.6. MSのプライマリDNSサーバ
Description
記述
The MS-Primary-DNS-Server Attribute is used to indicate the
address of the primary Domain Name Server (DNS) [16, 17] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
MSのプライマリDNSサーバAttributeは、PPP同輩によって使用されるようにプライマリDomain Name Server(DNS)[16、17]サーバのアドレスを示すのに使用されます。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
A summary of the MS-Primary-DNS-Server Attribute format is given below. The fields are transmitted left to right.
MSのプライマリDNSサーバAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 34] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[34ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| IP-アドレス+++++++++++++++++++++++++++++++++IP-アドレス(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
28 for MS-Primary-DNS-Server
MSのプライマリDNSサーバのためのベンダータイプ28
Vendor-Length
6
ベンダー長さの6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the primary DNS server.
IP-アドレス、IP-アドレス・フィールドは長さが4つの八重奏です。 それはプライマリDNSサーバのIPアドレスを含んでいます。
2.7.7. MS-Secondary-DNS-Server
2.7.7. MSのセカンダリDNSサーバ
Description
記述
The MS-Secondary-DNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
MSのセカンダリDNSサーバAttributeは、PPP同輩によって使用されるようにセカンダリDNSサーバのアドレスを示すのに使用されます。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
A summary of the MS-Secondary-DNS-Server Attribute format is given below. The fields are transmitted left to right.
MSのセカンダリDNSサーバAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| IP-アドレス+++++++++++++++++++++++++++++++++IP-アドレス(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
29 for MS-Secondary-DNS-Server
MSのセカンダリDNSサーバのためのベンダータイプ29
Vendor-Length
6
ベンダー長さの6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the secondary DNS server.
IP-アドレス、IP-アドレス・フィールドは長さが4つの八重奏です。 それはセカンダリDNSサーバのIPアドレスを含んでいます。
Zorn Informational [Page 35] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[35ページ]のRFC2548マイクロソフト
2.7.8. MS-Primary-NBNS-Server
2.7.8. MSのプライマリNBNSサーバ
Description
記述
The MS-Primary-NBNS-Server Attribute is used to indicate the
address of the primary NetBIOS Name Server (NBNS) [18] server to
be used by the PPP peer. It MAY be included in both Access-Accept
and Accounting-Request packets.
MSのプライマリNBNSサーバAttributeは、PPP同輩によって使用されるようにプライマリNetBIOS Name Server(NBNS)[18]サーバのアドレスを示すのに使用されます。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
A summary of the MS-Primary-MBNS-Server Attribute format is given below. The fields are transmitted left to right.
MSのプライマリMBNSサーバAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| IP-アドレス+++++++++++++++++++++++++++++++++IP-アドレス(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
30 for MS-Primary-NBNS-Server
MSのプライマリNBNSサーバのためのベンダータイプ30
Vendor-Length
6
ベンダー長さの6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the primary NBNS server.
IP-アドレス、IP-アドレス・フィールドは長さが4つの八重奏です。 それはプライマリNBNSサーバのIPアドレスを含んでいます。
2.7.9. MS-Secondary-NBNS-Server
2.7.9. MSのセカンダリNBNSサーバ
Description
記述
The MS-Secondary-NBNS-Server Attribute is used to indicate the
address of the secondary DNS server to be used by the PPP peer.
It MAY be included in both Access-Accept and Accounting-Request
packets.
MSのセカンダリNBNSサーバAttributeは、PPP同輩によって使用されるようにセカンダリDNSサーバのアドレスを示すのに使用されます。 それは、両方がAccess受け入れる含まれているコネとAccounting-リクエスト・パケットであるかもしれません。
A summary of the MS-Secondary-NBNS-Server Attribute format is given below. The fields are transmitted left to right.
MSのセカンダリNBNSサーバAttribute形式の概要を以下にします。 分野は右への伝えられた左です。
Zorn Informational [Page 36] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[36ページ]のRFC2548マイクロソフト
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | IP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP-Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ベンダータイプ| ベンダー長さ| IP-アドレス+++++++++++++++++++++++++++++++++IP-アドレス(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Type
31 for MS-Secondary-NBNS-Server
MSのセカンダリNBNSサーバのためのベンダータイプ31
Vendor-Length
6
ベンダー長さの6
IP-Address
The IP-Address field is 4 octets in length. It contains the IP
address of the secondary NBNS server.
IP-アドレス、IP-アドレス・フィールドは長さが4つの八重奏です。 それはセカンダリNBNSサーバのIPアドレスを含んでいます。
3. Table of Attributes
3. 属性のテーブル
The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity.
以下のテーブルは上の属性のどれがどの種類のパケット、およびどんな量に見つけられるかもしれないかにガイドを提供します。
Request Accept Reject Challenge Acct-Request # Attribute
0-1 0 0 0 0 1 MS-CHAP-Response
0 0 0-1 0 0 2 MS-CHAP-Error
0-1 0 0 0 0 3 MS-CHAP-CPW-1
0-1 0 0 0 0 4 MS-CHAP-CPW-2
0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW
0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW
0 0-1 0 0 0 7 MS-MPPE-Encryption-
Policy
0 0-1 0 0 0 8 MS-MPPE-Encryption-Type
0-1 0 0 0 0-1 9 MS-RAS-Vendor
0 0-1 0 0 0-1 10 MS-CHAP-Domain
0-1 0 0 0-1 0 11 MS-CHAP-Challenge
0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys
0 0-1 0 0 0 13 MS-BAP-Usage
0 0-1 0 0 0 14 MS-Link-Utilization-
Threshold
0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit
0 0-1 0 0 0 16 MS-MPPE-Send-Key
0 0-1 0 0 0 17 MS-MPPE-Recv-Key
0-1 0 0 0 0-1 18 MS-RAS-Version
0-1 0 0 0 0 19 MS-Old-ARAP-Password
0-1 0 0 0 0 20 MS-New-ARAP-Password
0 0 0 0-1 0 21 MS-ARAP-PW-Change-
Reason
さんのやつ応答0 0 0-1 0 0 2さんのやつ誤り0-1 0 0 0 0 3やつCPW-1 0-1 0 0 0 0 4廃棄物挑戦Acct-要求#属性0-1 0 0 0 0 1さんさんやつ-CPW-2 0+0 0 0 0 5やつLM-Enc-PWさんの0+0 0 0 0 6やつNT-Enc-PWさん0 0-1 0 0 0 7さんMPPE-暗号化方針0 0-1 0 0 0 8MPPE暗号化タイプさんの0-1 0 0 0 0-1 9MS RASベンダー0 0-1 0 0 0-1 10さんのやつドメイン0-1 0 0を受け入れるよう要求してください; 0-1 0 11やつ挑戦0 0-1 0 0 0MPPEさんがキーを送っているMS利用敷居0 0-1 0 0 0 15MSリンク低下タイムリミットをリンクしている0 0-1 0 0 0のMSの古いアラップパスワード0-1 0 0 0 0 20MSの新しいアラップパスワードやつMPPEキーさんの13MS BAP用法0 0-1 0 0 0 14 0 0-1 0 0 0 16 0 0-1 0 0 0 17MPPE-Recvキーさんの0-1 0 0 0 0-1 18MS RASバージョン0-1 0 0 0 0 19 0 0 0 0-1 0 21変化さん12PWアラップ-さん理由
Zorn Informational [Page 37] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[37ページ]のRFC2548マイクロソフト
0 0+ 0 0 0+ 22 MS-Filter
0 0 0 0 0-1 23 MS-Acct-Auth-Type
0 0 0 0 0-1 24 MS-Acct-EAP-Type
0-1 0 0 0 0 25 MS-CHAP2-Response
0 0-1 0 0 0 26 MS-CHAP2-Success
0-1 0 0 0 0 27 MS-CHAP2-CPW
0 0-1 0 0 0-1 28 MS-Primary-DNS-Server
0 0-1 0 0 0-1 29 MS-Secondary-DNS-Server
0 0-1 0 0 0-1 30 MS-Primary-NBNS-Server
0 0-1 0 0 0-1 31 MS-Secondary-NBNS-
Server
0-1 0 0 0 0 33 MS-ARAP-Challenge
MS Acct-AuthがタイプしているMS Acct-EAPがタイプしている0 0+0 0 0+22のMS-フィルタの0 0 0 0 0-1の23の0 0 0 0 0-1の24の0-1 0 0 0 0の25のCHAP2Responseさんの0 0-1 0 0 0の26のCHAP2Successさんの0-1 0 0 0 0の27のさん-CHAP2-CPWの0 0-1 0 0 0-1の28のMSのプライマリDNSサーバの0 0-1 0 0 0-1の29のMSのセカンダリDNSサーバの0 0-1 0 0 0-1の30のMSのプライマリNBNSサーバの0 0-1 0 0 0-1の31MSセカンダリのNBNSのサーバ0-1 0 0 0 0 33のアラップさんの挑戦
The following table defines the meaning of the above table entries.
以下のテーブルは上のテーブル項目の意味を定義します。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet.
0 この属性はパケットに存在しているはずがありません。 0+ゼロかこの属性の、より多くのインスタンスがパケットに存在しているかもしれません。 0-1 この属性のゼロか1つのインスタンスがパケットに存在しているかもしれません。
4. Security Considerations
4. セキュリティ問題
MS-CHAP, like PPP CHAP, is susceptible to dictionary attacks. User passwords should be chosen with care, and be of sufficient length to deter easy guessing.
PPP CHAPのように、さん-CHAPは辞書攻撃に影響されやすいです。 ユーザパスワードは、慎重に選ばれていて、簡単な推測を思いとどまらせることができるくらいの長さのものであるべきです。
Although the scheme used to protect the Keys field of the MS-CHAP- MPPE-Keys, MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes is believed to be relatively secure on the wire, RADIUS proxies will decrypt and re-encrypt the field for forwarding. Therefore, these attributes SHOULD NOT be used on networks where untrusted RADIUS proxies reside.
体系は以前はよくCHAP- MPPE Keysさんのキーズ分野を保護していました、MPPEさんがキーを送って、MPPE-Recv Key Attributesさんがワイヤで比較的安全であると信じられていますが、RADIUSプロキシは、推進のために分野を解読して、再暗号化するでしょう。 したがって、これらはSHOULD NOTを結果と考えます。信頼されていないRADIUSプロキシが住んでいるネットワークでは、使用されます。
5. Acknowledgements
5. 承認
Thanks to Carl Rigney (cdr@livingston.com), Ashwin Palekar (ash- winp@microsoft.com), Aydin Edguer (edguer@MorningStar.com), Narendra Gidwani (nareng@microsoft.com), Steve Cobb (stevec@microsoft.com), Pat Calhoun (pcalhoun@eng.sun.com), Dave Mitton (dmitton@baynetworks.com), Paul Funk (paul@funk.com), Gurdeep Singh Pall (gurdeep@microsoft.com), Stephen Bensley (sbens@microsoft.com), and Don Rule (don-aldr@microsoft.com) for useful suggestions and editorial feedback.
役に立つ提案と編集のフィードバックをカールRigney( cdr@livingston.com )、Ashwin Palekar(灰の winp@microsoft.com )、アイドゥンEdguer( edguer@MorningStar.com )、Narendra Gidwani( nareng@microsoft.com )、Steve Cobb( stevec@microsoft.com )、パットCalhoun( pcalhoun@eng.sun.com )、デーヴ・ミットン( dmitton@baynetworks.com )、ポールFunk( paul@funk.com )、GurdeepシンPall( gurdeep@microsoft.com )、スティーブンBensley( sbens@microsoft.com )、およびドンRule( don-aldr@microsoft.com )をありがとうございます。
Zorn Informational [Page 38] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[38ページ]のRFC2548マイクロソフト
6. Editor's Address
6. エディタのアドレス
Questions about this memo can 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
7. References
7. 参照
[1] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[1] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Access Dial In User Service", RFC 2138, April 1997.
[3]RigneyとC.とルーベンとA.とシンプソンとW.とS.ウィレンス、「ユーザサービスにおける遠隔アクセスのダイヤル」、RFC2138、1997年4月。
[4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433,
October 1998.
[4] ゾルンとG.とS.コッブ、「マイクロソフトpppやつ拡大」、RFC2433、1998年10月。
[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[5] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption
(MPPE) Protocol", Work in Progress.
[6] 「マイクロソフトの二地点間暗号化(MPPE)プロトコル」というゾルン、G.、およびG.祭服は進行中で働いています。
[7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[7] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[8] 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
[8] RC4は情報、接触を認可するRSA Data Security株式会社Forからライセンスの下で利用可能な独占暗号化アルゴリズムです: 海洋のParkwayレッドウッドシティー、RSA Data Security Inc.100カリフォルニア94065-1031
[9] Pall, G., "Microsoft Point-to-Point Compression (MPPC)
Protocol", RFC 2118, March 1997.
[9] 祭服、G.、「マイクロソフトの二地点間圧縮(MPPC)プロトコル」、RFC2118、1997年3月。
[10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
D.、「ppp圧縮制御プロトコル(CCP)」、RFC1962 1996年6月の[10]底ならし革。
Zorn Informational [Page 39] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[39ページ]のRFC2548マイクロソフト
[11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[11] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。
[12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation
Protocol (BAP) The PPP Bandwidth Allocation Control Protocol
(BACP)", RFC 2125, March 1997.
[12] リチャーズ、C.、およびK.スミス、「ppp帯域幅配分は(BAP)ppp帯域幅調節プロトコル(BACP)について議定書の中で述べます」、RFC2125、1997年3月。
[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[13] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in
Progress.
[14] ゾルン、「マイクロソフトpppやつ拡大(バージョン2インチ)は進行中で扱う」G.。
[15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[15]BlunkとL.と1998年のJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/ISI, November 1987.
[16]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、USC/ISI、11月1987日
[17] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[17]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS
Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,
March 1987.
[18] アウアーバック、K.、およびA.Aggarwalは「TCP/UDP輸送のときにNetBIOSサービスの規格について議定書の中で述べます」、STD19、RFCs1001と1002、1987年3月。
Zorn Informational [Page 40] RFC 2548 Microsoft Vendor-specific RADIUS Attributes March 1999
1999年の半径属性行進のときにベンダー特有のゾルン情報[40ページ]のRFC2548マイクロソフト
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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 Informational [Page 41]
ゾルンInformationalです。[41ページ]
一覧
スポンサーリンク
