RFC2548翻译

Network Working Group G. Zorn

Request for Comments: 2548 Microsoft Corporation

Category: Informational March 1999

 

Microsoft Vendor-specific RADIUS Attributes

Microsoft专有RADIUS特性

 

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.

 

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.

本文描述了一系列Microsoft专有RADIUS特性。这些特性设计来支持拨号认证协议和(或)提供对非标准RADIUS特性的支持。当Microsoft提供了新的专有特性的时候,本文档也应当更新,因为本文档的目的就是提供开放而简单的参考,以供有意愿的第三方程序可以和Microsoft的产品进行合作。

 

  1. Specification of Requirements

特别说明

 

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",

"recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as

described in [2].

本文中, "MAY", "MUST, "MUST NOT", "optional","recommended", "SHOULD", and "SHOULD NOT"等词都如字面意思一般,精确使用。

 

  1. Attributes

特性

 

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

之后的几个部分描述了一些在一个或多个专有特性中都会出现的子特性。不止这样的一个子特性可能出现在一个单独的专有特性中,如果出现这样的情况,这些子特性应该按照 Vendor-Type/Vendor-Length/Value的三元组进行打包,并且初始化。专有特性的长度必须按照必须等于该特性中所包含的所有子特性的长度 +6。 该专有属性的Vendor-ID必须被设置为十进制的311。

 

2.1. Attributes for Support of MS-CHAP Version 1

支持MS-CHAP Version 1的特性

 

2.1.1. Introduction

介绍

 

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:

Microsoft创造了Mircrosoft质询握手身份验证协议(MS-CHAP)对远程Windows工作站进行身份验证,以便适应基于局域网的用户。如果有可能 ,MS-CHAP是和CHAP一致的,不同指出也被很好的模块化。简单的说, MS-CHAP和标准的CHAP不同之处在于:

 

* MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP

option 3, Authentication Protocol.

MS-CHAP是基于CHAP在LCP option 3身份验证协议的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相应包与 Microsoft Windows NT 3.5, 3.51 and 4.0,

Microsoft Windows95, and 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定义了一系列扩展的 reason-for-failure codes,当包发送失败的时候就会返回。

 

The attributes defined in this section reflect these differences.

在这章里面涉及的特性就反应了这些不同之处。

 

2.1.2. MS-CHAP-Challenge

 

Description

 

This Attribute contains the challenge sent by a NAS to a Microsoft

Challenge-Handshake Authentication Protocol (MS-CHAP) user. It

MAY be used in both Access-Request and Access-Challenge packets.

这个特性存储NAS向 MS-CHAP提出的质询(challenge)。它可能被用于 Access-Request和 Access-Challenge的包。

 

 

A summary of the MS-CHAP-Challenge Attribute format is shown below.

The fields are transmitted from left to right.

下面是具体的 MS-CHAP-Challenge特性。按从左向右传输。

 

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.

 

Vendor-Length

> 2

 

String

The String field contains the MS-CHAP challenge.

 

2.1.3. MS-CHAP-Response

 

Description

 

This Attribute contains the response value provided by a PPP

Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP)

user in response to the challenge. It is only used in Access-

Request packets.

这个特性储存点对点的 MS-CHAP使用者对质询的回包。仅被用于 Access-

Request包。

 

A summary of the MS-CHAP-Response Attribute format is shown below.

The fields are transmitted from left to right.

 

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.

 

Vendor-Length

52

 

Ident

Identical to the PPP CHAP Identifier.

Ident 和点对点的CHAP的 Identifier一样

 

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长度为一个字节,如果为0x01,那么 NT-Response将会被优先使用, LM-Response虽然也会使用,但是要优先考虑NT-Response。如果为0,那么 NT-Response被忽略而 LM-Response会被选用。

 

 

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-Response长度为24个字节,用于保存密码以及收到的质询的加密方式。如果没有不使用那么应该用0来填充。

 

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-Response 长度为24个字节,用于保存密码以及收到的质询的加密方式。如果没有不使用那么应该用0来填充。

 

2.1.4. MS-CHAP-Domain

 

Description

 

The MS-CHAP-Domain Attribute indicates the Windows NT domain in

which the user was authenticated. It MAY be included in both

Access-Accept and Accounting-Request packets.

MS-CHAP-Domain特性用于指出在哪个 Windows NT domain里面进行身份认证。可能会用于Access-Accept和Accounting-Request包里面。

 

A summary of the MS-CHAP-Domain Attribute format is given below. The

fields are transmitted left to right.

 

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.

 

Vendor-Length

> 3

 

Ident

The Ident field is one octet and aids in matching requests and

replies.

Ident长度为1个字节,用于帮助匹配请求和回答

 

 

String

This field contains the name in ASCII of the Windows NT domain in

which the user was authenticated.

String包含用于身份验证的ASCII编码的Windows NT域名。

 

 

2.1.5. MS-CHAP-Error

 

Description

 

The MS-CHAP-Error Attribute contains error data related to the

preceding MS-CHAP exchange. This Attribute may be used in both

MS-CHAP-V1 and MS-CHAP-V2 (see below) exchanges. It is only used

in Access-Reject packets.

MS-CHAP-Error特性包含上次MS-CHAP数据交换 相关的数据。这个特性可以用于 MS-CHAP-V1和MS-CHAP-V2的数据交换,只能被用于Access-Reject包。

 

A summary of the MS-CHAP-Error Attribute format is given below. The

fields are transmitted left to right.

 

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.

 

Vendor-Length

> 3

 

Ident

The Ident field is one octet and aids in matching requests and

replies.

Ident长度为1个字节,用于帮助匹配请求和回答。

 

String

This field contains specially formatted ASCII text, which is

interpreted by the authenticating peer.

String包含特定的格式化的ASCII字符串,由身份验证的双方来约定格式。

 

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-CPW-1特性允许用户修改过期的密码。这个特性只用于 Access-Request包,并且应该只有在上次 Access-Reject包里面有MS-CHAP-Error特性,并且此特性里面的String指出用户的密码过期,而且 MS-CHAP的 version小于2的情况下,才能使用。

 

A summary of the MS-CHAP-CPW-1 Attribute format is shown below. The

fields are transmitted from left to right.

 

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

 

Vendor-Length

72

 

Code

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

Code长度为一个字节,并且总为5。

 

Ident

The Ident field is one octet and aids in matching requests and

replies.

Ident长度为一个字节,用于匹配请求和应答。

 

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-Old-Password长度为16个字节。它包含加密的旧密码的 Lan Manager hash值。(不清楚什么是 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-New-Password长度为16个字节。它包含加密的新密码的 Lan Manager hash值。(不清楚什么是 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-Old-Password 长度为16个字节。它包含加密的旧密码的 Lan Manager hash值。(不清楚什么是 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-Old-Password 长度为16个字节。它包含加密的新密码的 Lan Manager hash值。(不清楚什么是 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.

New-LM-Password-Length长度为2个字节,包含新的LAN Manager-compatible密码的用字节数表示的长度。

 

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个字节。如果最低有效位( the least significant

bit)为1,那么就说明 NT-New-

Password和NT-Old-Password应该是有效并且被使用,否则就是 LM-New-Password和LM-Old-Password被使用。

 

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-CPW-2特性允许用户修改过期的密码。这个特性只用于 Access-Request包,并且应该只有在上次 Access-Reject包里面有MS-CHAP-Error特性,并且此特性里面的String指出用户的密码过期,而且 MS-CHAP的 version等于2的情况下,才能使用。

 

A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The

fields are transmitted from left to right.

 

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

 

Vendor-Length

86

 

Code

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长度为1个字节,帮助匹配请求和应答。其值必须与同一个Access-

Request包中的 MS-CHAP-LM-Enc-PW, MS-CHAP-NT-

Enc-PW和MS-CHAP-PW-2中包含的Ident一致。

 

Old-NT-Hash

The Old-NT-Hash field is 16 octets in length. It contains the old

Windows NT password hash encrypted with the new Windows NT

password hash.

Old-NT-Hash长度为16个字节。包含用新Windows NT密码hash值加密的旧Windows NT密码的hash值。

 

Old-LM-Hash

The Old-LM-Hash field is 16 octets in length. It contains the old

Lan Manager password hash encrypted with the new Windows NT

password hash.

Old-LM-Hash长度为16个字节。包含用新Windows NT密码hash值加密的旧 Lan Manager 密码的hash值。

 

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-Response长度为24个字节。保存密码以及收到的质询的加密机制,如果此域没有被使用,应该用0来填充。

 

 

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-Response 长度为24个字节。保存密码以及收到的质询的加密机制,如果此域没有被使用,应该用0来填充。

 

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个字节。如果最低有效位(LBS)为1,那么 NT-Response将会优先使用, LM-Response也可能被用到(如果不是被0填充的话),但是NT-Response要优先尝试。如果LBS为0的话,那么 NT-Response必须被忽略,使用 LM-

Response来代替。而另外一位(应该是最高有效位)为1的话, Old-LM-Hash应该被使用。如果此位被设置的话,至少应该有一个 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.

MS-CHAP-LM-Enc-PW存储了用旧的LAN Manager密码hash值加密的新的Windows NT密码。这个加密的密码长度位516字节,因为这比单个RADIUS的特性的最大长度还要长,所以这个密码必须被切分到几个特性里面去传输。有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.

这个特性只能出现在Access-Request包里,和MS-CHAP-CPW-2一起。它只有在最近的 Access-Reject包里面包含了 MS-CHAP-Error特性,并且此特性的String指出 user password过期了,并且 MS-CHAP version大于等于2。

 

A summary of the MS-CHAP-LM-Enc-PW Attribute format is shown below.

The fields are transmitted from left to right.

 

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

 

Vendor-Length

> 6

 

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

 

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.

Indet长度为1个字节,用于匹配请求和应答。这个域的值必须和在同一个 Access-Request里面出现的 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.

Sequence-Number长度为2个字节,并且指出加密后的密码的哪一块在之后的String里面。

 

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

String包含了加密后的密码的一部分。

 

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.

MS-CHAP-NT-Enc-PW储存了用旧的 Windows NT 密码的hash值加密过的新的Windows NT密码。 这个加密的密码长度位516字节,因为这比单个RADIUS的特性的最大长度还要长,所以这个密码必须被切分到几个特性里面去传输。有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.

这个特性只能出现在Access-Request包里,和MS-CHAP-CPW-2 和 MS-CHAP2-CPW  一起。它只有在最近的 Access-Reject包里面包含了 MS-CHAP-Error特性,并且此特性的String指出 user password过期了,并且 MS-CHAP version大于等于2。

 

A summary of the MS-CHAP-NT-Enc-PW Attribute format is shown below.

The fields are transmitted from left to right.

 

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

 

Vendor-Length

> 6

 

Code

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

 

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.

Indet长度为1个字节,用于匹配请求和应答。这个域的值必须和在同一个 Access-Request里面出现的 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.

Sequence-Number长度为2个字节,并且指出加密后的密码的哪一块在之后的String里面。

 

String

The String field contains a portion of the encrypted password.

String包含了加密后的密码的一部分。

 

2.3. Attributes for Support of MS-CHAP Version 2

 

2.3.1. Introduction

 

This section describes RADIUS attributes supporting version two of

Microsoft's PPP CHAP dialect (MS-CHAP-V2) [14]. MS-CHAP-V2 is

similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1)

[4]. Certain protocol fields have been deleted or reused but with

different semantics. Where possible, MS-CHAP-V2 is consistent with

both MS-CHAP-V1 and standard CHAP [1]. Briefly, the differences

between MS-CHAP-V2 and MS-CHAP-V1 are:

本章描述支持微软实现的PPP CHAP的版本2的RADIUS特性。 MS-CHAP-V2和 MS-CHAP-V1类似但并不兼容。一些协议域被删除,或者用不同的语法进行重用。只要有可能, MS-CHAP-V2与 MS-CHAP-V1以及标准CHAP是一致的。简单来说, MS-CHAP-V2与MS-CHAP-V1的版本不同之处在于:

 

* MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP

option 3, Authentication Protocol.

MS-CHAP-V2是基于CHAP在LCP option 3身份验证协议的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 compatible challenge response"的计算修改为包含其中一方的质询和用户名。

 

* In MS-CHAP-V1, the "LAN Manager compatible challenge response"

sub-field was always sent in the Response packet. This field

has been replaced in MS-CHAP-V2 by the Peer-Challenge field.

MS-CHAP-V1中, "LAN Manager compatible challenge response"子域总是在应答包中发送。这个域在 MS-CHAP-V2被Peer-Challenge域所替代。

 

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

changed.

Message在失败包中的格式被修改了。

 

* The Change Password (version 1) and Change Password (version 2)

packets are no longer supported. They have been replaced with a

single Change-Password packet.

Change Password (version 1) and Change Password (version 2)包不再被支持。它们被一个单独的Change-Password包所替代。

 

The attributes defined in this section reflect these differences.

在本章中介绍的特性反应了这些不同。

 

2.3.2. MS-CHAP2-Response

 

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-CHAP2-Response 特性存储了 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.

 

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.

 

Vendor-Length

52

 

Ident

Identical to the PPP MS-CHAP v2 Identifier.

Ident与 PPP MS-CHAP v2标示相同。

 

Flags

The Flags field is one octet in length. It is reserved for future

use and MUST be zero.

FLags长度为1个字节。保留,必须为0.

 

Peer-Challenge

The Peer-Challenge field is a 16-octet random number.

Peer-Challenge是16个字节的随机数。

 

Reserved

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

Reserved保留,并且必须为0。

 

Response

The Response field is 24 octets in length and holds an encoded

function of the password, the Peer-Challenge field and the

received challenge.

Response长度为24个字节,储存密码的加密方式,

 

2.3.3. MS-CHAP2-Success

 

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.

MS-CHAP2-Success存储了长为42字节的验证者响应字符串。由NAS发送给其中一方的 MS-CHAP-

V2 Success包的Message里面必须包含这个字符串。这个特性只用于 Access-Accept包。

 

A summary of the MS-CHAP2-Success Attribute format is shown below.

The fields are transmitted from left to right.

 

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.

 

Vendor-Length

45

 

Ident

Identical to the PPP MS-CHAP v2 Identifier.

 

String

The 42-octet authenticator string (see above).

 

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.

MS-CHAP2-CPW特性允许用户修改过期的密码。这个特性只能与 MS-

CHAP-NT-Enc-PW特性在 Access-Request 包里面一起使用,并且应该只在最近的 Access-Reject包里面包含 MS-CHAP-Error特性时才能使用, MS-CHAP-Error特性的String要指出密码过期,并且 MS-CHAP的version为3。

 

A summary of the MS-CHAP-CPW-2 Attribute format is shown below. The

fields are transmitted from left to right.

 

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

 

Vendor-Length

70

 

Code

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长度为1,用以匹配请求和应答。这个域的值必须与所有 Access-Request包里面的 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.

Encrypted-Hash长度为16。它储存了用 new Windows NT

password的hash值加密的 old Windows NT password的hash值。

 

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-Response长度为24字节,存储了 new password, the Peer-Challenge field和the

received challenge的加密方式。

 

Flags

The Flags field is two octets in length. This field is reserved

for future use and MUST be zero.

Flags长度为2,保留,并且必须为0。

 

2.4. Attributes for MPPE Support

 

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

这章描述了一系列设计来支持使用拨号网络中Microsoft Point-to-Point Encryption (MPPE)的特性。

 

2.4.1. MS-CHAP-MPPE-Keys

 

Description

 

The MS-CHAP-MPPE-Keys Attribute contains two session keys for use

by the Microsoft Point-to-Point Encryption Protocol (MPPE). This

Attribute is only included in Access-Accept packets.

MS-CHAP-MPPE-Keys特性储存了两个由 Microsoft Point-to-Point Encryption Protocol (MPPE) 准备的以便使用的session key。这个特性只能用于 Access-Accept包。

 

A summary of the MS-CHAP-MPPE-Keys Attribute format is given below.

The fields are transmitted left to right.

 

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.

 

Vendor-Length

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.

Keys由两个逻辑上的子域组成:LM-Key和NT-Key。LM-Key长度为8个字节,存储函数 LmPasswordHash(P)输出的前8个字节。这个Hash值组成如下:用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-Key子域长度为6,存储 Windows NT的前六字节的hash值。明文 Keys的格式如下图描述。

 

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.

Keys必须由RADIUS服务器加密,要使用为User-Password特性定义的相同方法。要求要对齐,因为上面提到的方法要求域必须加密为一系列的六个字节。

 

Implementation Note

This attribute should only be returned in response to an

Access-Request packet containing MS-CHAP attributes.

实现时要注意,这个特性应该只应该在响应包含 MS-CHAP特性的Access-Request包的时候返回。

 

2.4.2. MS-MPPE-Send-Key

 

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 Encryption Protocol (MPPE)提供以便使用的 session key。如同特性名字描述的一般,这个key用于由NAS发送到远程服务器的加密包。这个属性只能被包含在 Access-Accept包中。

 

A summary of the MS-MPPE-Send-Key Attribute format is given below.

The fields are transmitted left to right.

 

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.

 

Vendor-Length

> 4

 

Salt

The Salt field is two octets in length and is used to ensure the

uniqueness of the keys used to encrypt each of the encrypted

attributes occurring in a given Access-Accept packet. The most

significant bit (leftmost) of the Salt field MUST be set (1). The

contents of each Salt field in a given Access-Accept packet MUST

be unique.

Salt长度为2个字节,用于保证在一个特定的 Access-Accept 包里面的用于加密每一个需要加密的特性的Keys的唯一性。Salt的最高有效位(最左边)必须为1。在一个特定的 Access-Accept 包里面每一个Salt的值都必须时唯一的。

 

String

The plaintext String field consists of three logical sub-fields:

the Key-Length and Key sub-fields (both of which are required),

and the optional Padding sub-field. The Key-Length sub-field is

one octet in length and contains the length of the unencrypted Key

sub-field. The Key sub-field contains the actual encryption key.

If the combined length (in octets) of the unencrypted Key-Length

and Key sub-fields is not an even multiple of 16, then the Padding

sub-field MUST be present. If it is present, the length of the

Padding sub-field is variable, between 1 and 15 octets. The

String field MUST be encrypted as follows, prior to transmission:

明文的String由三个逻辑子域构成: Key-Length和 Key sub-fields(都要有)以及 Padding。 Key-Length长度为1个字节,储存未加密的 Key子域的长度, Key储存实际加密的Key。如果未加密的 Key-Length以及Key组合起来的字节长度不是16的偶数倍,那么必须要有Padding。如果有Padding的话,其长度为1-15字节。String在传输之前,必须按照如下加密:

 

Construct a plaintext version of the String field by concate-

nating the Key-Length and Key sub-fields. If necessary, pad

the resulting string until its length (in octets) is an even

multiple of 16. It is recommended that zero octets (0x00) be

used for padding. Call this plaintext P.

String的明文版本由 Key-Length和 Key两个子域拼接而成,得到的字符的字节长度要被对齐为16的偶数倍。推荐用0字节来对齐。我们把这个字符串成为明文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):

我们称 the shared secret 为S,伪随机的128位 Request

Authenticator(来自对应的Access-Request包)为R,和Salt里面的内容为A。把P分为数个16个字节长度的块( chunks p(1), p(2)...p(i), where i = len(P)/16),我们把密文块称为 c(1), c(2)...c(i)以及最终的密文为C。中间值为 b(1), b(2)...b(i)。加密是按照下面的方式(‘+’代表拼接)。

 

b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)

b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)

. .

. .

. .

b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)

 

The resulting encrypted String field will contain

c(1)+c(2)+...+c(i).

最终的String由 c(1)+c(2)+...+c(i)组成。

 

On receipt, the process is reversed to yield the plaintext String.

这个过程也可以逆向产生明文。

 

 

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.

实现笔记,可能key返回的长度比实际的加密要求的多。如果这样,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)传递一个key给RADIUS服务器。在这种情况下,可能外部服务器不能正确地加密key,因为RADIUS的 shared secret可能得不到。但是,外部服务器应该返回如上所述的特性;Salt应该被0填充,并且String要被对齐。当RADIUS服务器从外部获得这个特性的时候,它必须在传输给RADIUS客户端之前,正确设置Salt和加密String。如果通讯 MS-MPPE-Send-Key特性的信道是可以被监听的话,那么这个特性必须被加密。

 

2.4.3. MS-MPPE-Recv-Key

 

Description

 

The MS-MPPE-Recv-Key Attribute contains a session key for use by

the Microsoft Point-to-Point Encryption Protocol (MPPE). As the

name implies, this key is intended for encrypting packets received

by the NAS from the remote host. This Attribute is only included

in Access-Accept packets.

MS-MPPE-Recv-Key特性存储 Microsoft Point-to-Point Encryption Protocol (MPPE)需要使用的1个 session key。就如它的名字一样,这个key是用于加密从远端服务器发送到NAS的包的。这个特性只能用于Access-Accept包。

 

A summary of the MS-MPPE-Recv-Key Attribute format is given below.

The fields are transmitted left to right.

 

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.

 

Vendor-Length

> 4

 

Salt

The Salt field is two octets in length and is used to ensure the

uniqueness of the keys used to encrypt each of the encrypted

attributes occurring in a given Access-Accept packet. The most

significant bit (leftmost) of the Salt field MUST be set (1). The

contents of each Salt field in a given Access-Accept packet MUST

be unique.

Salt长度为2个字节,用于保证在一个特定的 Access-Accept 包里面的用于加密每一个需要加密的特性的Keys的唯一性。Salt的最高有效位(最左边)必须为1。在一个特定的 Access-Accept 包里面每一个Salt的值都必须时唯一的。

 

String

The plaintext String field consists of three logical sub-fields:

the Key-Length and Key sub-fields (both of which are required),

and the optional Padding sub-field. The Key-Length sub-field is

one octet in length and contains the length of the unencrypted Key

sub-field. The Key sub-field contains the actual encryption key.

If the combined length (in octets) of the unencrypted Key-Length

and Key sub-fields is not an even multiple of 16, then the Padding

sub-field MUST be present. If it is present, the length of the

Padding sub-field is variable, between 1 and 15 octets. The

String field MUST be encrypted as follows, prior to transmission:

明文的String由三个逻辑子域构成: Key-Length和 Key sub-fields(都要有)以及 Padding。 Key-Length长度为1个字节,储存未加密的 Key子域的长度, Key储存实际加密的Key。如果未加密的 Key-Length以及Key组合起来的字节长度不是16的偶数倍,那么必须要有Padding。如果有Padding的话,其长度为1-15字节。String在传输之前,必须按照如下加密:

 

Construct a plaintext version of the String field by

concatenating the Key-Length and Key sub-fields. If necessary,

pad the resulting string until its length (in octets) is an

even multiple of 16. It is recommended that zero octets (0x00)

be used for padding. Call this plaintext P.

String的明文版本由 Key-Length和 Key两个子域拼接而成,得到的字符的字节长度要被对齐为16的偶数倍。推荐用0字节来对齐。我们把这个字符串成为明文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):

我们称 the shared secret 为S,伪随机的128位 Request

Authenticator(来自对应的Access-Request包)为R,和Salt里面的内容为A。把P分为数个16个字节长度的块( chunks p(1), p(2)...p(i), where i = len(P)/16),我们把密文块称为 c(1), c(2)...c(i)以及最终的密文为C。中间值为 b(1), b(2)...b(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).

 

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.

实现笔记,可能key返回的长度比实际的加密要求的多。如果这样,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)传递一个key给RADIUS服务器。在这种情况下,可能外部服务器不能正确地加密key,因为RADIUS的 shared secret可能得不到。但是,外部服务器应该返回如上所述的特性;Salt应该被0填充,并且String要被对齐。当RADIUS服务器从外部获得这个特性的时候,它必须在传输给RADIUS客户端之前,正确设置Salt和加密String。如果通讯 MS-MPPE-Recv-Key 特性的信道是可以被监听的话,那么这个特性必须被加密。

 

2.4.4. MS-MPPE-Encryption-Policy

 

Description

 

The MS-MPPE-Encryption-Policy Attribute may be used to signify

whether the use of encryption is allowed or required. If the

Policy field is equal to 1 (Encryption-Allowed), any or none of

the encryption types specified in the MS-MPPE-Encryption-Types

Attribute MAY be used. If the Policy field is equal to 2

(Encryption-Required), any of the encryption types specified in

the MS-MPPE-Encryption-Types Attribute MAY be used, but at least

one MUST be used.

MS-MPPE-Encryption-Policy特性 可以用于表明是否允许或需要加密。如果Policy等于1( Encryption-Allowed), MS-MPPE-Encryption-Types特性里面的加密类型都有可能被/不被使用到。如果 Policy等于2 (Encryption-Required), MS-MPPE-Encryption-Types特性里面都可以使用,但是至少有一个要被用到。

 

A summary of the MS-MPPE-Encryption-Policy Attribute format is given

below. The fields are transmitted left to right.

 

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.

 

Vendor-Length

6

 

Policy

The Policy field is 4 octets in length. Defined values are:

 

1 Encryption-Allowed 2 Encryption-Required

 

2.4.5. MS-MPPE-Encryption-Types

 

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-Encryption-Types特性用于指定可以和MPPE一同使用的加密类型。加密类型为长度为4个字节的整数,被解读为一个字符串。

 

A summary of the MS-MPPE-Encryption-Policy Attribute format is given

below. The fields are transmitted left to right.

 

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.

 

Vendor-Length

6

 

Policy

The Types field is 4 octets in length. The following diagram

illustrates the Types field.

 

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位设置了(我想就是为1的意思),RC4加密方法允许使用40位的key。如果S位被设置, RC4加密方法允许使用128位的key。如果都被设置了, RC4加密方法允许使用40位活着128位的key。

 

2.5. Attributes for BAP Support

 

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.

这章描述了一系列特有的设计来用于支持在 multilink PPP中动态控制带宽的Radius特性。这些特性用于表明在进来的呼叫之中,PPP Bandwidth Allocation Protocol的使用是否允许或者需要。线路的容量的警戒线,以及在掉线之前线路必须被减负的时间长度。

 

2.5.1. MS-BAP-Usage

 

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.

MS-BAP-Usage特性描述了BAP的使用是允许,不允许,或者在 new multilink calls时是否需要。它可以在 Access-Accept包中使用。

 

A summary of the MS-BAP-Usage Attribute format is shown below. The

fields are transmitted from left to right.

 

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.

 

Vendor-Length

6

 

Value

The Value field is four octets.

 

0 BAP usage not allowed

1 BAP usage allowed

2 BAP usage required

 

2.5.2. MS-Link-Utilization-Threshold

 

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-Link-Utilization-Threshold特性表示可用带宽的警戒线(低于多少百分比的时候链接就很容易断掉)。 MS-Link-

Utilization-Threshold特性的合法值为 1-100以内。只能被用于 Access-Accept包。

 

A summary of the MS-Link-Utilization-Threshold Attribute format is

shown below. The fields are transmitted from left to right.

 

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

 

Vendor-Length 6

 

Value The Value field is four octets in length and represents the

percentage of available bandwidth utilization below which the link

must fall before the link is eligible for termination.

Permissible values are in the range 1-100, inclusive.

Value的值长度为4,代表带宽警戒线。允许值在1-100之间。

 

2.5.3. MS-Link-Drop-Time-Limit

 

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-Link-Drop-Time-Limit特性指出链接必须减负(underutilized)的时间长度(以秒计算)。只能被用于 Access-Accept包。

 

A summary of the MS-Link-Drop-Time-Limit Attribute format is given

below. The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

Value

The Value field represents the number of seconds that a link must

be underutilized (i.e., display bandwidth utilization below the

threshold specified in the MS-Link-Utilization-Threshold

Attribute) before the link is dropped.

Value

Value表明减负的时间(根据 MS-Link-Utilization-Threshold特性里面定义的阀值)。

 

2.6. Attributes for ARAP Support

 

This section describes a set of Attributes designed to support the

Apple Remote Access Protocol (ARAP).

这章描述了一些烈设计来支持 Apple Remote Access Protocol (ARAP)的特性。

 

2.6.1. MS-Old-ARAP-Password

 

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-Old-ARAP-Password特性用来传输在修改ARAP密码操作中旧的ARAP密码。可以用在 Access-Request包中。

 

A summary of the MS-Old-ARAP-Password Attribute Attribute format is

given below. The fields are transmitted left to right.

 

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

 

Vendor-Length

> 3

 

String

The String field is one or more octets. It contains the old ARAP

password DES-encrypted using itself as the key.

String长度为1个或多个字节。它包含旧的用DES加密的ARAP密码,DES所用key为自身。

 

2.6.2. MS-New-ARAP-Password

 

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-New-ARAP-Password特性用于在ARAP密码修改操作过程中,传输新的 ARAP password。可以用于 Access-Request包。

 

A summary of the MS-New-ARAP-Password Attribute Attribute format is

given below. The fields are transmitted left to right.

 

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

 

Vendor-Length

> 3

 

String

The String field is one or more octets. It contains the new ARAP

password DES-encrypted using the old ARAP password as the key.

String长度为1个或多个字节。它包含新的用DES加密的ARAP密码,DES所用key为旧的 ARAP password。

 

2.6.3. MS-ARAP-Password-Change-Reason

 

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-Password-Change-Reason特性用于指出某次服务器导致的密码更改( a server-initiated password change)的原因。可以用在 Access-Challenge包里。

 

A summary of the MS-ARAP-Password-Change-Reason Attribute format is

given below. The fields are transmitted left to right.

 

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

 

Vendor-Length

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

 

2.6.4. MS-ARAP-Challenge

 

Description

 

This attribute is only present in an Access-Request packet

containing a Framed-Protocol Attribute with the value 3 (ARAP).

MS-ARAP-Challenge特性只用于表示在 Access-Request包中包含值为3的 Framed-Protocol特性。

 

A summary of the MS-ARAP-Challenge Attribute format is given below.

The fields are transmitted left to right.

 

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

 

Vendor-Length

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.

Value长度为8个字节。存储由NAS发送到peer的质询。

 

2.7. Miscellaneous Attributes

 

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.

这章描述了一系列其它章节没有描述的特性,但是用于Microsoft远程登录产品的认证和操作。

 

2.7.1. MS-RAS-Vendor

 

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-Vendor特性用于指出RADIUS客户端机器的制造商。可以用于 Access-

Request包和 Accounting-Request包。

 

A summary of the MS-RAS-Vendor Attribute format is given below. The

fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

Vendor-ID

The Vendor-ID field is 4 octets in length. The high-order octet

is 0 and the low-order 3 octets are the SMI Network Management

Private Enterprise Code of the Vendor in network byte order, as

defined in the Assigned Numbers RFC[13].

Vendor-ID长度为4个字节。高位的0个字节和低位的3个字节按照网络字节序排列的 the SMI Network Management

Private Enterprise Code of the Vendor,就如 Assigned Numbers RFC所定义的一样。

 

2.7.2. MS-RAS-Version

 

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-Vendor特性的包也应该同时有 MS-RAS-Version这个特性。 不包含有 MS-RAS-Vendor特性的包也不应该有 MS-RAS-Version这个特性。可以用于 Access-Request包和 Accounting-Request包。

 

A summary of the MS-RAS-Version Attribute format is given below. The

fields are transmitted left to right.

 

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

 

Vendor-Length

> 3

 

String

The String field is one or more octets. The actual format of the

information is vendor specific, and a robust implementation SHOULD

support the field as undistinguished octets.

String长度为1个或者多个字节。信息的世纪格式由厂家自行定义,健壮的实现应该是用常用的方式。

 

2.7.3. MS-Filter

 

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-Accept包和Accounting-Request包。

 

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-Filter特性包含在同一个包里面,它们必须按顺序排列,并且必须连续排列在同一个包里面。

 

A summary of the MS-Filter Attribute format is given below. The

fields are transmitted left to right.

 

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

 

Vendor-Length

> 3

 

Filter

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

undifferentiated octets.

Filter长度为1个或者多个字节。它包含了一系列无差别的字节。

 

If multiple MS-Filter Attributes occur in a single Access-Accept

packet, the Filter field from each MUST be concatenated in the

order received to form the actual filter.

如果多个MS-Filter特性出现在同一个 Access-Accept包里,那么Filter必须按照接受顺序拼接起来形成最终使用的filter。

 

2.7.4. MS-Acct-Auth-Type

 

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特性用于指明验证拨号用户的方法。可以包含在 Accounting-Request包中。

 

A summary of the MS-Acct-Auth-Type Attribute format is given below.

The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

Auth-Type

The Auth-Type field is 4 octets in length. The following values

are defined for this field:

 

PAP 1

CHAP 2

MS-CHAP-1 3

MS-CHAP-2 4

EAP 5

 

2.7.5. MS-Acct-EAP-Type

 

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特性用于表明验证拨号用户的 Extensible

Authentication Protocol的类型。可以用于Accounting-Request包。

 

A summary of the MS-Acct-EAP-Type Attribute format is given below.

The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

Auth-Type

The EAP-Type field is 4 octets in length. The following values

are currently defined for this field:

 

MD5 4

OTP 5

Generic Token Card 6

TLS 13

 

2.7.6. MS-Primary-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-Primary-DNS-Server特性用于指出 PPP peer使用的 主DNS地址。可以在 Access-Accept包和Accounting-Request包中使用。

 

A summary of the MS-Primary-DNS-Server Attribute format is given

below. The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

IP-Address

The IP-Address field is 4 octets in length. It contains the IP

address of the primary DNS server.

IP-Address长度为4个字节。包含了主DNS服务器的IP地址。

 

2.7.7. MS-Secondary-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-Secondary-DNS-Server 特性用于指出 PPP peer使用的次DNS地址。可以在 Access-Accept包和Accounting-Request包中使用。

 

A summary of the MS-Secondary-DNS-Server Attribute format is given

below. The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

IP-Address

The IP-Address field is 4 octets in length. It contains the IP

address of the secondary DNS server.

IP-Address 长度为4个字节。包含了次DNS服务器的IP地址。

 

2.7.8. MS-Primary-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-Primary-NBNS-Server 特性用于指出 PPP peer使用的主NBNS地址。可以在 Access-Accept包和Accounting-Request包中使用。

 

A summary of the MS-Primary-MBNS-Server Attribute format is given

below. The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

IP-Address

The IP-Address field is 4 octets in length. It contains the IP

address of the primary NBNS server.

IP-Address长度为4个字节。包含了主 NBNS 服务器的IP地址。

 

2.7.9. MS-Secondary-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-Secondary-NBNS-Server 特性用于指出 PPP peer使用的次NBNS地址。可以在 Access-Accept包和Accounting-Request包中使用。

 

A summary of the MS-Secondary-NBNS-Server Attribute format is given

below. The fields are transmitted left to right.

 

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

 

Vendor-Length

6

 

IP-Address

The IP-Address field is 4 octets in length. It contains the IP

address of the secondary NBNS server.

IP-Address长度为4个字节。包含了次NBNS 服务器的IP地址。

 

3. Table of Attributes

 

The following table provides a guide to which of the above attributes

may be found in which kinds of packets, and in what quantity.

下面的表格便于查找在哪种包里面可以找到上述的属性以及数量。

 

Request Accept Reject Challenge Acct-Request # Attribute

0-1 0 0 0 0 1 MS-CHAP-Response

0 0 0-1 0 0 2 MS-CHAP-Error

0-1 0 0 0 0 3 MS-CHAP-CPW-1

0-1 0 0 0 0 4 MS-CHAP-CPW-2

0+ 0 0 0 0 5 MS-CHAP-LM-Enc-PW

0+ 0 0 0 0 6 MS-CHAP-NT-Enc-PW

0 0-1 0 0 0 7 MS-MPPE-Encryption-

Policy

0 0-1 0 0 0 8 MS-MPPE-Encryption-Type

0-1 0 0 0 0-1 9 MS-RAS-Vendor

0 0-1 0 0 0-1 10 MS-CHAP-Domain

0-1 0 0 0-1 0 11 MS-CHAP-Challenge

0 0-1 0 0 0 12 MS-CHAP-MPPE-Keys

0 0-1 0 0 0 13 MS-BAP-Usage

0 0-1 0 0 0 14 MS-Link-Utilization-

Threshold

0 0-1 0 0 0 15 MS-Link-Drop-Time-Limit

0 0-1 0 0 0 16 MS-MPPE-Send-Key

0 0-1 0 0 0 17 MS-MPPE-Recv-Key

0-1 0 0 0 0-1 18 MS-RAS-Version

0-1 0 0 0 0 19 MS-Old-ARAP-Password

0-1 0 0 0 0 20 MS-New-ARAP-Password

0 0 0 0-1 0 21 MS-ARAP-PW-Change-

Reason

 

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

 

The following table defines the meaning of the above table entries.

 

0 This attribute MUST NOT be present in packet.

0表示没有。

0+ Zero or more instances of this attribute MAY be present in packet.

0+表示可以有0个或者多个。

0-1 Zero or one instance of this attribute MAY be present in packet.

0-1表示可以有0个或者1个。

 

4. Security Considerations

 

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-Keys, MS-MPPE-Send-Key 和 MS-MPPE-Recv-Key特性的加密是可以被信任,但由于RADIUS的Proxy要解密和再加密,所以应该谨慎选择信任的RADIUS的Proxy。

 

5. Acknowledgements

 

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.

 

6. Editor's Address

 

Questions about this memo can be directed to:

 

Glen Zorn

Microsoft Corporation

One Microsoft Way

Redmond, Washington 98052

 

Phone: +1 425 703 1559

Fax: +1 425 936 7329

EMail: glennz@microsoft.com

 

7. References

 

[1] Simpson, W., "PPP Challenge Handshake Authentication

Protocol (CHAP)", RFC1994, August 1996.

 

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC2119, March 1997.

 

[3] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote

Access Dial In User Service", RFC2138, April 1997.

 

[4] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC2433,

October 1998.

 

[5] Simpson, W., "PPP Challenge Handshake Authentication Protocol

(CHAP)", RFC1994, August 1996.

 

[6] Zorn, G. and G. Pall, "Microsoft Point-to-Point Encryption

(MPPE) Protocol", Work in Progress.

 

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

1661, July 1994.

 

[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

 

[9] Pall, G., "Microsoft Point-to-Point Compression (MPPC)

Protocol", RFC2118, March 1997.

 

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

1962, June 1996.

 

[11] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,

"The PPP Multilink Protocol (MP)", RFC1990, August 1996.

 

[12] Richards, C. and K. Smith, "The PPP Bandwidth Allocation

Protocol (BAP) The PPP Bandwidth Allocation Control Protocol

(BACP)", RFC2125, March 1997.

 

[13] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC1700,

October 1994.

 

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

Progress.

 

[15] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication

Protocol (EAP)", RFC2284, March 1998.

 

[16] Mockapetris, P., "Domain Names - Concepts and Facilities", STD

13, RFC1034, USC/ISI, November 1987.

 

[17] Mockapetris, P., "Domain Names - Implementation and

Specification", STD 13, RFC1035, November 1987.

 

[18] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS

Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002,

March 1987.

 

10. Full Copyright Statement

 

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

 

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

 

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.

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页