[要約] RFC 2548は、Microsoft Vendor-specific RADIUS Attributesに関する仕様を定義しています。このRFCの目的は、Microsoftの特定のベンダー固有のRADIUS属性を定義し、ネットワーク認証やアクセス制御などの目的で使用することです。

Network Working Group                                            G. Zorn
Request for Comments: 2548                         Microsoft Corporation
Category: Informational                                       March 1999
        
              Microsoft Vendor-specific RADIUS Attributes
        

Status of this Memo

このメモの位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1999). All Rights Reserved.

著作権(C)インターネット協会(1999)。全著作権所有。

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属性のセットを記述します。これらの属性は、Microsoft独自のダイヤルアッププロトコルをサポートおよび/または設定された標準RADIUS属性によって提供されていない機能のサポートを提供するように設計されている[3]。 Microsoftが新しいベンダー固有の属性を定義したときに、その主な目的は、マイクロソフト製品との相互運用を希望するサードパーティのオープン、容易にアクセス参照を提供するものであるため、このメモは、更新されることが期待されます。

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].

この文書に記載されている、キーワード "MAY"、「MUST、 "MUST NOT"、 "オプション"、 "推奨"、 "SHOULD"、および "the" [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).

以下のセクションでは、[3]式ベンダー固有の1つまたは複数のRADIUS属性で送信することができるサブ属性を記述する。複数のサブ属性は、単一のベンダー固有の属性で送信されても​​よいです。これが行われた場合、サブ属性はベンダータイプ/ベンダー長さ/値はinitalタイプ、長さとベンダーIDフィールド、次のトリプルのシーケンスとしてパックされるべきです。ベンダー固有属性の長さフィールドは、ベンダー固有の属性に含まれるサブ属性、プラス6のベンダー長フィールドの和に等しく設定されなければなりません。ベンダー固有の属性(複数可)のベンダーIDフィールド311(Microsoft)を進数に設定されなければなりません。

2.1. Attributes for Support of MS-CHAP Version 1
2.1. MS-CHAPバージョン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:

マイクロソフトは、LANベースのユーザーが慣れていると機能を提供する、[4]リモートのWindowsワークステーションを認証するために、Microsoftチャレンジハンドシェイク認証プロトコル(MS-CHAP)を作成しました。可能な場合、MS-CHAPは、標準的なCHAP [5]と一致している、との違いは容易にモジュール化されています。簡単に言えば、MS-CHAPと標準のCHAPの違いは以下のとおりです。

* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP option 3, Authentication Protocol.

* MS-CHAPは、LCPオプション3、認証プロトコルでCHAPアルゴリズムは0x80を交渉することによって有効になります。

* 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.

* MS-CHAP Responseパケットは、Microsoft Windows NT 3.5、3.51および4.0、マイクロソフトのWindows95、およびMicrosoft LAN Managerの2.xのネットワーク製品との互換性のために設計されたフォーマットです。 MS-CHAP形式では、クリアテキストまたは可逆暗号化されたパスワードを保存するために、認証を必要としません。

* MS-CHAP provides an authenticator-controlled authentication retry mechanism.

* MS-CHAPは、認証制御認証再試行メカニズムを提供します。

* MS-CHAP provides an authenticator-controlled password changing mechanism.

* MS-CHAPは、認証制御パスワードの変更機構を提供します。

* MS-CHAP defines an extended set of reason-for-failure codes, returned in the Failure packet Message field.

* MS-CHAPは、理由のために、故障コードの拡張セットを定義し、失敗パケットのメッセージフィールドに返されます。

The attributes defined in this section reflect these differences.

このセクションで定義された属性は、これらの違いを反映しています。

2.1.2. MS-CHAP-Challenge
2.1.2. MS-CHAPチャレンジ

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.

この属性は、Microsoftチャレンジハンドシェイク認証プロトコル(MS-CHAP)ユーザーにNASによって送られた課題が含まれています。これは、アクセス要求とアクセスチャレンジパケットの両方で使用されるかもしれません。

A summary of the MS-CHAP-Challenge Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAPチャレンジ属性形式の概要は以下に示されています。フィールドは左から右に送信されます。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 11 for MS-CHAP-Challenge.

MS-CHAPチャレンジのためのベンダータイプ11。

Vendor-Length > 2

ベンダー長さ> 2

String The String field contains the MS-CHAP challenge.

文字列文字列]フィールドには、MS-CHAPチャレンジが含まれています。

2.1.3. MS-CHAP-Response
2.1.3. MS-CHAP-レスポンス

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.

この属性は、チャレンジに応答してPPP Microsoftチャレンジハンドシェイク認証プロトコル(MS-CHAP)ユーザーによって提供された応答値が含まれています。これは、唯一のAccess-Requestパケットで使用されています。

A summary of the MS-CHAP-Response Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAPレスポンス属性形式の概要は以下に示されています。フィールドは左から右に送信されます。

    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)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 1 for MS-CHAP-Response.

MS-CHAP-応答のためのベンダータイプ1。

Vendor-Length 52

ベンダー長さ52

Ident Identical to the PPP CHAP Identifier.

PPP CHAP識別子と同じです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-レスポンスが最初に試行すべきです。それがゼロである場合は、NT-レスポンスフィールドは無視され、LMレスポンスフィールドを使用しなければなりません。

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個のオクテットで、パスワードと受信したチャレンジの符号化機能を保持しています。このフィールドが空の場合、それはゼロ埋めるべき。

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個のオクテットで、パスワードと受信したチャレンジの符号化機能を保持しています。このフィールドが空の場合、それはゼロ埋めるべき。

2.1.4. MS-CHAP-Domain
2.1.4. MS-CHAPドメイン

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.

MS-CHAP-domain属性は、ユーザーが認証されたWindows NTドメインを示します。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-CHAP-Domain Attribute format is given below. The fields are transmitted left to right.

MS-CHAPドメイン属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 10 for MS-CHAP-Domain.

MS-CHAP-ドメインのベンダータイプ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.

文字列このフィールドは、ユーザーが認証されたWindows NTドメインのASCIIに名前が含まれています。

2.1.5. MS-CHAP-Error
2.1.5. MS-CHAP-エラー

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.

MS-CHAP-エラー属性が先行MS-CHAPの交換に関連するエラーデータを含みます。この属性は、MS-CHAP-V1およびMS-CHAP-V2(下記参照)の交換の両方に使用することができます。これはのみのアクセス拒否パケットで使用されています。

A summary of the MS-CHAP-Error Attribute format is given below. The fields are transmitted left to right.

MS-CHAP-エラー属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 2 for MS-CHAP-Error.

MS-CHAP-エラーのためのベンダータイプ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.

文字列このフィールドは、認証ピアによって解釈される特別な形式のASCIIテキストが含ま。

2.1.6. MS-CHAP-CPW-1
2.1.6. MS-CHAP-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.

この属性は、期限が切れたときに、ユーザーが自分のパスワードを変更することができます。この属性は、唯一のアクセス要求パケットで使用され、MS-CHAP-エラー属性が直前のアクセス拒否パケットに含まれていた場合にのみ含まれるべき、MS-CHAP-エラー属性の文字列フィールドには、ユーザーことが示されパスワードの有効期限が切れていた、とMS-CHAPバージョンが2未満です。

A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP-CPW-1項目のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 3 for MS-CHAP-PW-1

MS-CHAP-PW-1のベンダータイプ3

Vendor-Length 72

ベンダー長さ72

Code The Code field is one octet in length. Its value is always 5.

コードザ・Codeフィールドは、長さは1つのオクテットです。この値は常に5です。

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オクテットです。これは、古いパスワードの暗号化されたLAN Managerのハッシュが含まれています。

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オクテットです。これは、新しいパスワードの暗号化されたLAN Managerのハッシュが含まれています。

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オクテットです。これは、古いパスワードの暗号化されたLAN Managerのハッシュが含まれています。

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オクテットです。これは、新しいパスワードの暗号化されたLAN Managerのハッシュが含まれています。

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.

新-LM-パスワードの長さは、New-LM-パスワード-Lengthフィールドの長さは2つのオクテットで、新たなLAN Managerの互換パスワードのオクテットの長さが含まれています。

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-旧・パスワードフィールドが有効であり、使用されるべきであることを示しています。それ以外の場合は、LM-新パスワードとLM-旧 - [パスワード]フィールドを使用しなければなりません。

2.1.7. MS-CHAP-CPW-2
2.1.7. MS-CHAP-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.

この属性は、期限が切れたときに、ユーザーが自分のパスワードを変更することができます。この属性は、唯一のアクセス要求パケットで使用され、MS-CHAP-エラー属性が直前のアクセス拒否パケットに含まれていた場合にのみ含まれるべき、MS-CHAP-エラー属性の文字列フィールドには、ユーザーことが示されパスワードの有効期限が切れていた、とMS-CHAPバージョンは2に等しいです。

A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP-CPW-2属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 4 for MS-CHAP-PW-2

MS-CHAP-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つのオクテットとエイズです。このフィールドの値は、MS-CHAP-NT-ENC-PWと、MS-CHAP-LM-ENC-PWのすべてのインスタンスでのIdentフィールドにそれと同一でなければならないMS-CHAP-PW-2に含まれている属性単一のAccess-Requestパケット。

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.

旧-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.

旧-LM-ハッシュオールド-LM-ハッシュフィールドは、長さが16オクテットです。これは、新しいWindows NTパスワードハッシュで暗号化された古いLAN Managerのパスワードハッシュが含まれています。

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個のオクテットで、パスワードと受信したチャレンジの符号化機能を保持しています。このフィールドが空の場合、それはゼロ埋めるべき。

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個のオクテットで、パスワードと受信したチャレンジの符号化機能を保持しています。このフィールドが空の場合、それはゼロ埋めるべき。

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-レスポンスが最初に試行すべきです。フィールドの最下位ビットがゼロの場合は、NT-レスポンスフィールドは無視され、LMレスポンスフィールドが代わりに使用しなければなりません。フラグフィールドのビット1が1である場合には、旧-LM-ハッシュフィールドが有効であり、使用されるべきです。このビットが設定されている場合、MS-CHAP-LM-ENC-PW属性の少なくとも1つのインスタンスは、パケットに含まれなければなりません。

2.1.8. MS-CHAP-LM-Enc-PW
2.1.8. MS-CHAP-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.

この属性は、古いLAN Managerパスワードハッシュで暗号化された新しい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.

この属性は、MS-CHAP-CPW-2の属性と一緒に、アクセス要求パケットで使用されています。 MS-CHAP-エラー属性が直前のアクセス拒否のパケットに含まれていたなら、それだけ含まれるべき、MS-CHAP-エラー属性の文字列フィールドには、ユーザーのパスワードの有効期限が切れたことを示し、およびMS-CHAPバージョンがあります2以上です。

A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP-LM-ENC-PW属性形式の概要は以下に示されています。フィールドは左から右に送信されます。

    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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 5 for MS-CHAP-LM-Enc-PW

MS-CHAP-LM-ENC-PWのためのベンダータイプ5

Vendor-Length > 6

ベンダー長> 6

Code 6. Code is the same as for the MS-CHAP-PW-2 attribute.

コード6コードはMS-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つのオクテットとエイズです。同じアクセス要求中に存在するこのフィールドの値は、MS-CHAP-LM-ENC-PWのすべてのインスタンスで同じでなければなりません、MS-CHAP-NT-ENC-PWおよびMS-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.

シーケンス番号は、シーケンス番号フィールドの長さは2つのオクテットで、暗号化パスワードの「チャンク」は、以下の文字列]フィールドに含まれているかを示します。

String The String field contains a portion of the encrypted password.

文字列文字列]フィールドには、暗号化されたパスワードの一部が含まれています。

2.2. MS-CHAP-NT-Enc-PW
2.2. MS-CHAP-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.

この属性は、古いの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.

この属性は、MS-CHAP-CPW-2およびMS-CHAP2-CPW属性を持つconjunc - ションでは、Access-Requestパケットで使用されています。 MS-CHAP-エラー属性が直前のアクセス拒否のパケットに含まれていたなら、それだけ含まれるべき、MS-CHAP-エラー属性の文字列フィールドには、ユーザーのパスワードの有効期限が切れたことを示し、およびMS-CHAPバージョンがあります2以上です。

A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP-NT-ENC-PW属性形式の概要は以下に示されています。フィールドは左から右に送信されます。

    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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 6 for MS-CHAP-NT-Enc-PW

MS-CHAP-NT-ENC-PWのためのベンダータイプ6

Vendor-Length > 6

ベンダー長> 6

Code 6. Code is the same as for the MS-CHAP-PW-2 attribute.

コード6コードはMS-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つのオクテットとエイズです。同じアクセス要求中に存在するこのフィールドの値は、MS-CHAP-LM-ENC-PWのすべてのインスタンスで同じでなければなりません、MS-CHAP-NT-ENC-PWおよびMS-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.

シーケンス番号は、シーケンス番号フィールドの長さは2つのオクテットで、暗号化パスワードの「チャンク」は、以下の文字列]フィールドに含まれているかを示します。

String The String field contains a portion of the encrypted password.

文字列文字列]フィールドには、暗号化されたパスワードの一部が含まれています。

2.3. Attributes for Support of MS-CHAP Version 2
2.3. MS-CHAPバージョン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:

このセクションでは、RADIUSは、MicrosoftのPPP CHAP方言(MS-CHAP-V2)[14]のバージョン2をサポートしている属性を記述しています。 MS-CHAP-V2 [4] MS-CHAPバージョン1(MS-CHAP-V1)に類似するが、互換性がありません。特定のプロトコルフィールドはなく、異なる意味を持つ削除または再利用されています。可能な場合、MS-CHAP-V2 [1] MS-CHAP-V1および標準CHAPの両方と一致しています。簡潔には、MS-CHAP-V2およびMS-CHAP-V1の違いは次のとおりです。

* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP option 3, Authentication Protocol.

* MS-CHAP-V2は、LCPオプション3、認証プロトコルでCHAPアルゴリズム0x81との交渉で有効になっています。

* MS-CHAP-V2 provides mutual authentication between peers by piggybacking a peer challenge on the Response packet and an authenticator response on the Success packet.

* MS-CHAP-V2は、応答パケットにピアチャレンジ、成功パケットにオーセンティケータ応答をピギーバックすることによって、ピア間の相互認証を提供します。

* The calculation of the "Windows NT compatible challenge response" sub-field in the Response packet has been changed to include the peer challenge and the user name.

*応答パケットの「Windows NT互換性のあるチャレンジレスポンス」サブフィールドの計算は、ピアチャレンジとユーザー名を含むように変更されました。

* In MS-CHAP-V1, the "LAN Manager compatible challenge response" sub-field was always sent in the Response packet. This field has been replaced in MS-CHAP-V2 by the Peer-Challenge field.

* MS-CHAP-V1では、「LAN Managerの互換性のあるチャレンジレスポンス」サブフィールドは常に応答パケットに送信されました。このフィールドは、ピアチャレンジフィールドでMS-CHAP-V2に置き換えられました。

* The format of the Message field in the Failure packet has been changed.

*失敗パケット内のメッセージフィールドのフォーマットが変更されました。

* The Change Password (version 1) and Change Password (version 2) packets are no longer supported. They have been replaced with a single Change-Password packet.

*パスワードの変更(バージョン1)およびパスワードの変更(バージョン2)パケットはサポートされなくなりました。彼らは、単一の変更、パスワードのパケットに置き換えられました。

The attributes defined in this section reflect these differences.

このセクションで定義された属性は、これらの違いを反映しています。

2.3.2. MS-CHAP2-Response
2.3.2. MS-CHAP2レスポンス

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.

この属性は、チャレンジに応答して、MS-CHAP-V2ピアによって提供された応答値を含んでいます。これは、唯一のAccess-Requestパケットで使用されています。

A summary of the MS-CHAP2-Response Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP2レスポンス属性形式の概要は以下に示されています。フィールドは左から右に送信されます。

    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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 25 for MS-CHAP2-Response.

MS-CHAP2-応答のためのベンダータイプ25。

Vendor-Length 52

ベンダー長さ52

Ident Identical to the PPP MS-CHAP v2 Identifier.

PPP MS-CHAP v2の識別子に同一IDENT。

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.

ピアチャレンジフィールドをピアに挑戦16オクテット乱数です。

Reserved This field is reserved for future use and MUST be zero.

予約済みこのフィールドは、将来の使用のために予約されており、ゼロでなければなりません。

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.

レスポンスレスポンスフィールドは、長さが24個のオクテットであり、パスワード、ピアチャレンジフィールドと受信したチャレンジの符号化機能を保持しています。

2.3.3. MS-CHAP2-Success
2.3.3. MS-CHAP2 - 成功

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.

この属性は、42オクテットの認証側応答文字列が含まれています。この文字列はピアにNASから送信されたMS-CHAP-V2成功パケットのメッセージフィールドに含まれなければなりません。この属性は、接続許可パケットで使用されています。

A summary of the MS-CHAP2-Success Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP2-成功属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 26 for MS-CHAP2-Success.

MS-CHAP2 - 成功のためのベンダータイプ26。

Vendor-Length 45

ベンダー長さ45

Ident Identical to the PPP MS-CHAP v2 Identifier.

PPP MS-CHAP v2の識別子に同一IDENT。

String The 42-octet authenticator string (see above).

ストリング42オクテット認証文字列(上記参照)。

2.3.4. MS-CHAP2-CPW
2.3.4. MS-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.

この属性は、期限が切れたときに、ユーザーが自分のパスワードを変更することができます。この属性は唯一のAccess-RequestパケットでMS-CHAP-NT-ENC-PW属性と一緒に使用され、およびMS-CHAP-エラー属性が直前に含まれていた場合にのみ含まれるべきパケット、アクセス拒否MS-CHAP-エラー属性の文字列フィールドには、ユーザーのパスワードの有効期限が切れたことを示し、およびMS-CHAPバージョンは3に等しいです。

A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The fields are transmitted from left to right.

MS-CHAP-CPW-2属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 27 for MS-CHAP2-PW

MS-CHAP2-PWのためのベンダータイプ27

Vendor-Length 70

ベンダー長さ70

Code 7

コード7

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つのオクテットとエイズです。このフィールドの値は、アクセス要求パケットに含まれるMS-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.

暗号化・ハッシュは、暗号化、ハッシュフィールドは、長さが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個のオクテットで、新しいパスワード、ピアチャレンジフィールドと受信したチャレンジの符号化機能を保持しています。

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].

このセクションでは、[6]ダイヤルアップネットワークでMicrosoft Point-to-Point暗号化(MPPE)の使用をサポートするように設計された属性のセットを記述する。 MPPEは、プロトコル(PPP)暗号化された形式で[7]のパケットをポイント・ツー・ポイントを表現する手段です。 MPPEは、暗号化のためのRSA RC4 [8]アルゴリズムを使用しています。暗号化テーブルを初期化するために使用されるセッションキーの長さを交渉することができます。 MPPEは現在、40ビットおよび128ビットのセッションキーをサポートしています。 MPPEは、PPP圧縮制御プロトコル(CCP)にオプション18内に交渉され[9]、[10]。

2.4.1. MS-CHAP-MPPE-Keys
2.4.1. MS-CHAP-MPPE-キー

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.

MS-CHAP-MPPE-キー属性は、Microsoft Point-to-Point暗号化プロトコル(MPPE)により使用するための2つのセッション鍵が含まれています。この属性は、接続許可パケットに含まれています。

A summary of the MS-CHAP-MPPE-Keys Attribute format is given below. The fields are transmitted left to right.

MS-CHAP-MPPE-キー属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 12 for MS-CHAP-MPPE-Keys.

MS-CHAP-MPPE-キーのベンダータイプ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.

LM-キーとNT-キー:キーキーフィールドには、二つの論理のサブフィールドで構成されます。 LM-キーは、8バイトの長さであると、関数LmPasswordHash(Pの出力の最初の8つのバイトが含まれ、このハッシュは以下のように構築された:プレーンテキストのパスワードは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個のオクテットが含まれています。平文キーフィールドのフォーマットは、次の図に示されています。

      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)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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.

キーフィールドは、ユーザパスワード項目[3]のために定義されたのと同じ方法を使用して、RADIUSサーバによって暗号化されなければなりません。上記で参照方法は、長さが16オクテットの倍数になるように暗号化されるフィールドを必要とするので、パディングが必要です。

Implementation Note This attribute should only be returned in response to an Access-Request packet containing MS-CHAP attributes.

実装上の注意は、この属性は、MS-CHAPの属性を含むアクセス要求パケットに応答して返されるべきです。

2.4.2. MS-MPPE-Send-Key
2.4.2. MS-MPPE-SENDキー

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.

MS-MPPE-Send-Key属性は、Microsoft Point-to-Point暗号化プロトコル(MPPE)により使用するためのセッションキーが含まれています。名前が示すように、このキーは、リモートホストにNASから送信されたパケットを暗号化するためのものです。この属性は、接続許可パケットに含まれています。

A summary of the MS-MPPE-Send-Key Attribute format is given below. The fields are transmitted left to right.

MS-MPPEは-SEND-キー属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 16 for MS-MPPE-Send-Key.

MS-MPPE-SENDキーのベンダータイプ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.

塩ザ塩フィールドの長さは2つのオクテットであり、所与のアクセス受諾パケットに発生する暗号化された属性のそれぞれを暗号化するために使用されるキーの一意性を保証するために使用されます。ソルトフィールドの最上位ビット(左端)は、(1)設定しなければなりません。与えられたアクセス・受け入れパケット内の各ソルトフィールドの内容は一意でなければなりません。

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:

文字列は、平文の文字列フィールドには、3つの論理サブフィールドから構成:キー長とKeyサブフィールド(どちらも必要とされる)、およびオプションのパディングサブフィールド。キーの長さサブフィールドの長さは1つのオクテットで、暗号化されていない主なサブフィールドの長さが含まれています。キーのサブフィールドは、実際の暗号化キーが含まれています。暗号化されていないキーの長さおよびキーのサブフィールド(オクテットで)結合した長さが16の倍数でない場合、パディングサブフィールドが存在しなければなりません。それが存在する場合、パディングサブフィールドの長さは1と15オクテットの間に、可変です。次のように文字列フィールドは、送信前に、暗号化されなければなりません。

         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.
        

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):

(2)(1)、P 16のオクテットチャンクPに共有秘密Sを呼び出し、擬似ランダム128ビット要求認証(対応するアクセス要求パケットから)R、および塩フィールドA.ブレークPの内容... P(I)、I = LEN(P)/ 16。暗号文ブロックC(1)、C(2)、...、C(i)を呼び出して、最終的な暗号文Cの中間体は、B(1)、B(2)... 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)

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).

結果として暗号化された文字列フィールドは、c(1)+ C(2)+ ... + C(i)を含んでいます。

On receipt, the process is reversed to yield the plaintext 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.

実装は、返されたキーの長さが使用されている暗号化方式のために必要なよりも大きくすることができる可能性があり注意します。この場合、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共有秘密が使用できない場合がありますので、外部のサーバーが正しく、キーを暗号化するために、この場合には、それができない場合があります。上記で定義された外部サーバは、しかし、属性を返すべきです。ソルトフィールドはゼロ充填し、文字列フィールドのパディングが行われるべきであるべきです。 RADIUSサーバが外部サーバから属性を受け取ると、それは正しくソルトフィールドを設定し、RADIUSクライアントに送信する前に文字列フィールドを暗号化する必要があります。チャネルは、MS-MPPE-Send-Key属性は、盗聴から保護されていない通信するために使用される場合、属性が暗号で保護されなければなりません。

2.4.3. MS-MPPE-Recv-Key
2.4.3. MS-MPPE-Recv関数キー

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.

MS-MPPE-Recv-Key属性は、Microsoft Point-to-Point暗号化プロトコル(MPPE)により使用するためのセッションキーが含まれています。名前が示すように、このキーは、リモートホストからのNASが受信したパケットを暗号化するためのものです。この属性は、接続許可パケットに含まれています。

A summary of the MS-MPPE-Recv-Key Attribute format is given below. The fields are transmitted left to right.

MS-MPPE-Recv-Key属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 17 for MS-MPPE-Recv-Key.

MS-MPPE-Recv関数キーのベンダータイプ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.

塩ザ塩フィールドの長さは2つのオクテットであり、所与のアクセス受諾パケットに発生する暗号化された属性のそれぞれを暗号化するために使用されるキーの一意性を保証するために使用されます。ソルトフィールドの最上位ビット(左端)は、(1)設定しなければなりません。与えられたアクセス・受け入れパケット内の各ソルトフィールドの内容は一意でなければなりません。

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:

文字列は、平文の文字列フィールドには、3つの論理サブフィールドから構成:キー長とKeyサブフィールド(どちらも必要とされる)、およびオプションのパディングサブフィールド。キーの長さサブフィールドの長さは1つのオクテットで、暗号化されていない主なサブフィールドの長さが含まれています。キーのサブフィールドは、実際の暗号化キーが含まれています。暗号化されていないキーの長さおよびキーのサブフィールド(オクテットで)結合した長さが16の倍数でない場合、パディングサブフィールドが存在しなければなりません。それが存在する場合、パディングサブフィールドの長さは1と15オクテットの間に、可変です。次のように文字列フィールドは、送信前に、暗号化されなければなりません。

         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.
        

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): 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)

(2)(1)、P 16のオクテットチャンクPに共有秘密Sを呼び出し、擬似ランダム128ビット要求認証(対応するアクセス要求パケットから)R、および塩フィールドA.ブレークPの内容... P(I)、I = LEN(P)/ 16。暗号文ブロックC(1)、C(2)、...、C(i)を呼び出して、最終的な暗号文Cの中間体は、B(1)、B(2)... 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).

結果として暗号化された文字列フィールドは、c(1)+ C(2)+ ... + C(i)を含んでいます。

On receipt, the process is reversed to yield the plaintext 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.

実装は、返されたキーの長さが使用されている暗号化方式のために必要なよりも大きくすることができる可能性があり注意します。この場合、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共有秘密が使用できない場合がありますので、外部のサーバーが正しく、キーを暗号化するために、この場合には、それができない場合があります。上記で定義された外部サーバは、しかし、属性を返すべきです。ソルトフィールドはゼロ充填し、文字列フィールドのパディングが行われるべきであるべきです。 RADIUSサーバが外部サーバから属性を受け取ると、それは正しくソルトフィールドを設定し、RADIUSクライアントに送信する前に文字列フィールドを暗号化する必要があります。 MS-MPPE-Recv-Key属性を通信するために使用されるチャネルが盗聴から保護されていない場合は、属性が暗号で保護されなければなりません。

2.4.4. MS-MPPE-Encryption-Policy
2.4.4. MS-MPPE-暗号化 - ポリシー

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.

MS-MPPE暗号化ポリシー属性は、暗号化の使用が許可または必要とされているかどうかを示すために使用することができます。 Policyフィールドが1(暗号化-可)に等しい場合、いずれか、またはMS-MPPE-暗号化・タイプで指定された暗号化タイプのどれも属性を使用することができます。 Policyフィールドが2(暗号化 - 必須)に等しい場合、MS-MPPE-暗号化・タイプで指定された暗号化タイプの任意の属性を使用することができるが、少なくとも一つを使用しなければなりません。

A summary of the MS-MPPE-Encryption-Policy Attribute format is given below. The fields are transmitted left to right.

MS-MPPE暗号化ポリシー属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 7 for MS-MPPE-Encryption-Policy.

MS-MPPE-暗号-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. MS-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.

MS-MPPE-暗号化 - タイプはMPPEで使用できる暗号化の種類を示すために使用される属性。これは、ビット列として解釈される4つのオクテットの整数です。

A summary of the MS-MPPE-Encryption-Policy Attribute format is given below. The fields are transmitted left to right.

MS-MPPE暗号化ポリシー属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 8 for MS-MPPE-Encryption-Types.

MS-MPPE-暗号化・タイプのベンダータイプ8。

Vendor-Length 6

ベンダー長さ6

Policy The Types field is 4 octets in length. The following diagram illustrates the Types field.

ポリシータイプフィールドの長さは4つのオクテットです。次の図は、タイプフィールドを示しています。

         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ビットが設定されている場合、RC4 [5] 40ビットの鍵を用いた暗号化が許可されます。 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]に帯域幅割り当ての動的制御をサポートするように設計されたベンダー固有のRADIUS属性のセットを記述する。属性はそれがPPP帯域幅割り当てプロトコル(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.

この属性は、BAPの使用は、許可不許可にするか、新しいマルチリンク通話に必要とされるかどうかについて説明します。これは、接続許可パケットで使用されるかもしれません。

A summary of the MS-BAP-Usage Attribute format is shown below. The fields are transmitted from left to right.

MS-BAP-使用属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 13 for MS-BAP-Usage.

MS-BAP-使用のためのベンダータイプ13。

Vendor-Length 6

ベンダー長さ6

Value The Value field is four octets.

値値フィールドは4つのオクテットです。

         0      BAP usage not allowed
         1      BAP usage allowed
         2      BAP usage required
        
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.

この属性は、リンクは、終了の対象になる前に、リンクが落ちなければならないの下に利用可能な帯域幅の使用率を表しています。 MS-リンク利用-threshold属性の許容値は、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-リンク利用-threshold属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。

    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)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 14 for MS-Link-Utilization-Threshold

MS-リンク利用-thresholdにはベンダータイプ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.

値は、値フィールドの長さは4つのオクテットであり、リンクが終了の対象になる前に、リンクが落ちなければならないの下に利用可能な帯域幅の使用率を表しています。許容値は、1〜100の範囲に含まれています。

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-リンクドロップ期限属性は、それがドロップされる前に、リンクが十分に利用されなければならない時間(秒)の長さを示します。それだけで、接続許可パケットに含まれるかもしれません。

A summary of the MS-Link-Drop-Time-Limit Attribute format is given below. The fields are transmitted left to right.

MS-リンクドロップ期限属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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.

値値フィールドは、リンクが十分に活用されなければならない秒数を表す(すなわち、MS-リンク利用-threshold属性で指定された閾値以下表示帯域幅利用)リンクの前には廃棄されます。

2.6. Attributes for ARAP Support
2.6. ARAPのサポートのための属性

This section describes a set of Attributes designed to support the Apple Remote Access Protocol (ARAP).

このセクションでは、Appleリモートアクセスプロトコル(ARAP)をサポートするように設計された属性のセットを記述する。

2.6.1. MS-Old-ARAP-Password
2.6.1. MS-旧-ARAP-パスワード

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-password属性は、ARAPパスワード変更操作の間に古いARAPパスワードを送信するために使用されます。これは、アクセス要求パケットに含まれるかもしれません。

A summary of the MS-Old-ARAP-Password Attribute Attribute format is given below. The fields are transmitted left to right.

MS-旧-ARAP-パスワードの概要は以下の通りであるフォーマット属性属性。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 19 for MS-Old-ARAP-Password Attribute

MS-旧-ARAP-パスワード属性のためのベンダータイプ19

Vendor-Length > 3

ベンダー長さ> 3

String The String field is one or more octets. It contains the old ARAP password DES-encrypted using itself as the key.

文字列の文字列フィールドは1オクテット以上です。これは、キーとしての地位を利用してDESで暗号化された古いARAPパスワードが含まれています。

2.6.2. MS-New-ARAP-Password
2.6.2. MS-新ARAP - パスワード

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 - パスワード属性がARAPパスワード変更操作の間に、新しいARAPパスワードを送信するために使用されます。これは、アクセス要求パケットに含まれるかもしれません。

A summary of the MS-New-ARAP-Password Attribute Attribute format is given below. The fields are transmitted left to right.

MS-新ARAP - パスワードの概要は以下の通りであるフォーマット属性属性。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 20 for MS-New-ARAP-Password Attribute

MS-新ARAP - パスワード属性のためのベンダータイプ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.

文字列の文字列フィールドは1オクテット以上です。これは、キーとして古いARAPパスワードを使用して、新しいARAPパスワードDES暗号化が含まれています。

2.6.3. MS-ARAP-Password-Change-Reason
2.6.3. MS-ARAP-パスワード変更-理由

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.

MS-ARAP-パスワード変更-理由属性は、サーバ起動パスワード変更の理由を示すために使用されます。これは、アクセスチャレンジパケットに含まれるかもしれません。

A summary of the MS-ARAP-Password-Change-Reason Attribute format is given below. The fields are transmitted left to right.

MS-ARAP-パスワード変更-理由属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 21 for MS-ARAP-Password-Change-Reason

MS-ARAP-パスワード変更-理由のためのベンダータイプ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

なぜ、なぜ、フィールドの長さは4つのオクテットです。次の値が定義されています:ジャスト・パスワード変更1期限切れ-パスワードを2管理者は、必要-パスワードの変更3パスワード短すぎる4

2.6.4. MS-ARAP-Challenge
2.6.4. MS-アラブ・チャレンジ

Description

説明

This attribute is only present in an Access-Request packet containing a Framed-Protocol Attribute with the value 3 (ARAP).

この属性は、値3(ARAP)で囲まプロトコル属性を含むアクセス要求パケットにのみ存在します。

A summary of the MS-ARAP-Challenge Attribute format is given below. The fields are transmitted left to right.

MS-ARAPチャレンジ属性形式の概要は以下の通りです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 33 for MS-ARAP-Challenge

MS-ARAPチャレンジのためのベンダータイプ33

Vendor-Length 10

ベンダー長さ10

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.

バリューザ・チャレンジフィールドの長さは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-ベンダー属性は、RADIUSクライアント・マシンの製造元を示すために使用されます。これは、アクセス要求およびアカウンティング要求パケットの両方に含まれるかもしれません。

A summary of the MS-RAS-Vendor Attribute format is given below. The fields are transmitted left to right.

MS-RAS-ベンダー属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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].

ベンダーIDザベンダーIDフィールドは、長さが4つのオクテットです。上位オクテットは0で、割り当て番号RFC [13]で定義されている下位3つのオクテットは、ネットワークバイト順でベンダーのSMIネットワーク管理プライベートエンタープライズコードです。

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 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-version属性は、RADIUSクライアントソフトウェアのバージョンを示すために使用されます。この属性は、MS-RAS-ベンダー属性を含むパケットに含まれるべきです。それはMS-RAS-ベンダー属性が含まれていないパケットで送るべきではありません。これは、アクセス要求およびアカウンティング要求パケットの両方に含まれるかもしれません。

A summary of the MS-RAS-Version Attribute format is given below. The fields are transmitted left to right.

MS-RAS-Version属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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.

文字列の文字列フィールドは1オクテット以上です。情報の実際のフォーマットは、ベンダー固有であり、かつ強固な実装が平凡なオクテットとしてフィールドをサポートする必要があります。

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-filter属性は、トラフィックフィルタを送信するために使用されます。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

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-フィルタ属性は、パケット内に含まれている場合、彼らは順序である必要があり、彼らは、パケット内の連続属性でなければなりません。

A summary of the MS-Filter Attribute format is given below. The fields are transmitted left to right.

MS-フィルタ属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 22 for MS-Filter Attribute

MS-filter属性のためのベンダータイプ22

Vendor-Length > 3

ベンダー長さ> 3

Filter The Filter field is one or more octets. It contains a sequence of undifferentiated octets.

[フィルタ]フィールドが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-フィルタ属性は、単一のアクセス受諾パケットに発生した場合、それぞれのフィルタフィールドが順に連結されなければならないが、実際のフィルタを形成するために受け取りました。

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-type属性は、ダイヤルアップユーザを認証するために使用される方法を表すために使用されます。これは、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Acct-Auth-Type Attribute format is given below. The fields are transmitted left to right.

MS-ACCT-AUTH-type属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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-Typeフィールドの長さは4つのオクテットです。次の値は、このフィールドに定義されています。

         PAP               1
         CHAP              2
         MS-CHAP-1         3
         MS-CHAP-2         4
         EAP               5
        
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-type属性は、ダイヤルアップユーザを認証するために使用される拡張認証プロトコル(EAP)[15]タイプを表すために使用されます。これは、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Acct-EAP-Type Attribute format is given below. The fields are transmitted left to right.

MS-ACCT-EAP-type属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

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-Typeフィールドの長さは4つのオクテットです。次の値は、現在このフィールドに定義されています。

         MD5                    4
         OTP                    5
         Generic Token Card     6
         TLS                    13
        
2.7.6. MS-Primary-DNS-Server
2.7.6. MS-プライマリ-DNS-Serverの

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-server属性がプライマリドメインネームサーバ(DNS)のアドレスを示すために使用されている[16、17]サーバは、PPPピアによって使用されます。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Primary-DNS-Server Attribute format is given below. The fields are transmitted left to right.

MS-プライマリ-DNS-Serverの属性のフォーマットの概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 28 for MS-Primary-DNS-Server

MS-プライマリ-DNS-Serverのベンダータイプ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-Serverの

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-Serverの属性は、PPPピアによって使用されるセカンダリDNSサーバーのアドレスを示すために使用されます。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Secondary-DNS-Server Attribute format is given below. The fields are transmitted left to right.

MS-セカンダリ-DNS-Serverの属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 29 for MS-Secondary-DNS-Server

MS-セカンダリ-DNS-Serverのベンダータイプ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アドレスが含まれています。

2.7.8. MS-Primary-NBNS-Server
2.7.8. MS-プライマリ-NBNS-Serverの

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-server属性は、PPPピアによって使用されるプライマリNetBIOSネームサーバ(NBNS)[18]サーバのアドレスを示すために使用されます。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Primary-MBNS-Server Attribute format is given below. The fields are transmitted left to right.

MS-初代MBNS-server属性形式の概要は以下のとおりです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 30 for MS-Primary-NBNS-Server

MS-プライマリ-NBNS-Serverのベンダータイプ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-Serverの

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-server属性は、PPPピアによって使用されるセカンダリDNSサーバーのアドレスを示すために使用されます。これは、両方のAccess-受け入れ、アカウンティング要求パケットに含まれるかもしれません。

A summary of the MS-Secondary-NBNS-Server Attribute format is given below. The fields are transmitted left to right.

MS-二次NBNS-server属性のフォーマットの概要は以下の通りです。フィールドは左から右へ送信されています。

    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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Vendor-Type 31 for MS-Secondary-NBNS-Server

MS-二-NBNS-Serverのベンダータイプ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-1 0 0 0 0 1 MS-CHAP-レスポンス属性0 0 0-1 0 0 2 MS-CHAP-エラー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-暗号化・ポリシー0 0-1 0 0 8 MS-MPPE暗号化タイプ0-1 0 0 0-1 9 MS-RASベンダ0 0-1 0 0- 1 10 MS-CHAPドメイン0-1 0 0-1 0 11 MS-CHAPチャレンジ0 0-1 0 0 12 MS-CHAP-MPPE-キー0 0-1 0 0 13 MS-BAP-使用0-1 0 0 0 14 0 MS-リンク利用率、しきい値0 0-1 0 0 0 15 MS-リンクドロップ期限0 0-1 0 0 0 16 MS-MPPEは、送信キー0 0- 1 0 0 17 MS-MPPE-Recv関数キー0-1 0 0 0-1 18 MS-RAS-版0-1 0 0 0 0 19 MS-旧ARAP-パスワード0-1 0 0 0 0 20 MS-新ARAP - パスワード0 0 0 0-1 0 21 MS-ARAP-PW-変更-理由

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

0 0+ 0 0+ 22 MS-フィルタ0 0 0 0 0-1 23 MS-ACCT-AUTH-タイプ0 0 0 0 0-1 24 MS-ACCT-EAP-タイプ0-1 0 0 0 0 25 MS -CHAP2レスポンス0 0-1 0 0 0 26 MS-CHAP2-成功0-1 0 0 0 0 27 MS-CHAP2-CPW 0 0-1 0 0 0-1 28 MS-プライマリ-DNS-Serverの0 0- 1 0 0 0-1 29 MS-二次DNSサーバー-0 0-1 0 0-1 30 MS-プライマリ-NBNS-サーバ0 0-1 0 0-1 31 MS-二次NBNS-サーバ0- 1 0 0 0 0 33 MS-ARAPチャレンジ

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.

MS-CHAPは、PPP 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.

MS-CHAP-MPPE-キーのキーフィールドを保護するために使用する方式で、MS-MPPE-SENDキーおよびMS-MPPE-Recv関数キー属性がワイヤ上の比較的安全であると考えられているが、RADIUSプロキシは、解読し、転送のためにフィールドを再暗号化。したがって、これらの属性は、信頼できない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(ash-winp@microsoft.com)、アイディンEdguer(edguer@MorningStar.com)、ナレンドラGidwani(nareng@microsoft.com)、スティーブ・コブ(stevec .COM)、パットカルフーン(pcalhoun@eng.sun.com)、デイヴ・ミトン(dmitton@baynetworks.com)、ポール・ファンク(paul@funk.com)、ガーディープ・シンポール(gurdeep@microsoft.com)、スティーブン・Bensley( sbens@microsoft.com)、ドン・ルール(don-aldr@microsoft.com)便利な提案や編集のフィードバックのために。

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 1559ファックス:+1 425 936 7329 Eメール:glennz@microsoft.com

7. References
7.参考

[1] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[1]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル(CHAP)"、RFC 1994、1996年8月。

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[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. Willens、 "ユーザーサービスでリモートアクセスダイヤル"、RFC 2138、1997年4月。

[4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.

[4]ソーン、G.とS.コブ、 "マイクロソフトPPP CHAP拡張機能"、RFC 2433、1998年10月。

[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

[5]シンプソン、W.、 "PPPチャレンジハンドシェイク認証プロトコル(CHAP)"、RFC 1994、1996年8月。

[6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption (MPPE) Protocol", Work in Progress.

[6]ソーン、G.とG.ポール、 "Microsoft Point-to-Point暗号化(MPPE)プロトコル" が進行中で働いています。

[7] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

[7]シンプソン、W.、 "ポイントツーポイントプロトコル(PPP)"、STD 51、RFC 1661、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データセキュリティ社からライセンスの下で利用可能な独自の暗号化アルゴリズムです:RSA Data Security社の100マリンパークウェイレッドウッドシティー、カリフォルニア州94065から1031

[9] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", RFC 2118, March 1997.

[9]ポール、G.、 "マイクロソフトポイントツーポイント圧縮(MPPC)プロトコル"、RFC 2118、1997年3月。

[10] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.

[10]ランド、D.、 "PPP圧縮制御プロトコル(CCP)"、RFC 1962、1996年6月。

[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)"、RFC 1990、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)"、RFC 2125、1997年3月。

[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

[13]レイノルズ、J.およびJ.ポステル、 "割り当て番号"、STD 2、RFC 1700、1994年10月。

[14] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", Work in Progress.

[14]ソーン、G.、 "マイクロソフトPPP CHAP拡張、Version 2" が進行中で働いています。

[15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.

[15]ブルンク、L.及びJ. Vollbrecht、 "PPP拡張認証プロトコル(EAP)"、RFC 2284、1998年3月。

[16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/ISI, November 1987.

[16] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034 USC / ISI、1987年11月。

[17] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[17] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。

[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.アガルワル、 "TCP / UDPトランスポート上のNetBIOSサービスのプロトコル標準"、STD 19、RFCの1001,1002、1987年3月。

10.完全な著作権声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

著作権(C)インターネット協会(1999)。全著作権所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。